极限编程（Extreme Programming）简介

 

极限编程

1.       什么是极限编程

2.       极限编程的12大实践

3.       极限编程过程

4.       极限编程策略

5.       极限编程vsCMMI

 

1.       极限编程

极限编程（以下称XP）是关于软件开发的新方法论。她是Kent Beck在参与戴姆斯.克莱斯勒公司的一个叫C3的项目时首先提出的。

XP的出现彻底颠覆了软件工程的某些核心思想。事实证明，在某些客观情况下，XP理论可以指导开发出高质量的软件产品并提高生产力。

XP是基于一套并非是最新但却是非高效的技术上的。XP要让软件开发项目充满乐趣、成效卓著，并且在可控中稳定地为企业创造价值。

 

1.1        XP基本原理

XP最大化使用所采用的技术，所以称之为“极限”。

a.       结对编程（pair programming）。一人编程，另一人同时在一旁审查代码。

b.       客户参与测试。

c.       每个程序员都成为架构师。

d.       一天数次集成测试。

e.       数周或数天一次迭代。

f.        区分商业利益和项目负责人的决策、总在编程之前编写单元测试并让所有测试保持在运行状态、集成并测试整个系统、程序员结对而生产软件、从简单的设计开始项目并不断改进以增加必要的灵活性与去除不必要的复杂性、将最小的系统迅速投产并朝证实其价值的方向发展。

“极限编程只是适合于那些需求不明或需求变化快的项目中的小开发团队的方法论。”

                                                           -- Kent Beck

 

1.2        XP的特性

a.       四种价值：沟通、简便、反馈、勇气。

b.       五个准则：提供反馈、简单设计、增量的改变、热衷于改变、质量保证工作

c.       十二个实践：客户入驻项目组；小的版本；隐喻；测试；简单设计；精化；结对编程；计划；每周40小时工作；持续集成；确定代码的所有权人；编程规范。

 

1.2.1          四种价值

a.       沟通（communication）：一个项目不论是项目组与客户之间，还是开发人员之间都需要持续的沟通。

b.       简单（simplicity）：把一系列的工作习题简单化。简单明了的设计便于以后的扩展。

c.       反馈（feedback）：不断从客户那里获取反馈，做迭代式开发。基于测试案例的开发（Test-base programming），即先开发测试案例，再写代码。

d.       勇气（courage）：综合了上述三种价值后，我们必定是干劲十足的，无畏的。

 

1.2.2          五条准则

a.       快速反馈（rapid feedback）：在极限编程项目中，开发者尽可能快速的提供和获取反馈。

b.       简单设计（assume simplicity）：只为当前的迭代做设计。要求每个人做计划，设计重构。做测试以保证将来可以加入更复杂的需求。

c.       增量式变化（incremental change）：需求、设计、代码等等，在每次解决问题时只对这一系列的步骤做微小的同步的改动。对于XP方法论的采用也是渐进的。

d.       包容变化（embrace change）：

e.       质保工作（quality work）：

 

1.3        XP是独特的

在短的迭代中及早地，具体地，持续地反馈。

增量地计划步骤。

基于不断变化的需求弹性的执行进度表。

信任程序员写的测试用例。

信任程序员的团队协作。

 

1.4        问题

a. 什么是极限编程？

极限编程只是适合于那些需求不明或需求变化快的项目中的小开发团队的方法论。

b. 极限编程的四种价值？

沟通，简洁，反馈，勇气。

 

 

 

 

 

 

2.     极限编程的12种实践

2.1      现场客户

很多软件项目的失利都缘于对未能正确表述客户的需求。真正的客户应该成为项目团队的一员，由他来定义客户需求，回答并解决需求相关的问题，将功能排出优先级。

 

2.2      小的发布版本

先实现重要的功能。短的迭代周期，制订一到两个月的迭代计划肯定比六到十二个月的迭代计划更容易。

 

2.3      暗喻/架构

将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

 

2.4      测试

自动测试驱动。

在编码之前写测试用例。

随时做单元测试与集成测试。

单元测试必须百分之百地通过。

 

2.5      简单设计

简单但须正确：能跑通所有的测试用例；代码重用性非常高；类和方法越少越好；实现当前的所有功能需求。只为今天而不是为将来作设计。

 

2.6      精炼

重构的系统里不能包含正在改变的功能。

目标：保持设计简洁。如果发现不合理的设计就修改，删去那些无用的代码。

 

2.7      配对编程

两人同时使用一台机器编程。一个写代码，另一人则考虑如何改进。

两人的角色随时可以更换。

好处：没有人在任何方面是内行，所以可以在工作中学习，并持续的检测。

缺点：浪费开发时间。两人之间不易管理。

 

2.8      设计

需求判定：开发的范围，功能优先级，各版本的内容，各版本的发布日期

技术判定：各功能模块完成所需的时间估算，详细阐述需求判定的结果，团队的组织架构，进度表。

 

2.9      每周40小时工作时间

开发人员按时下班。任何超时工作的项目都需要精简，重新设计，重新做计划。

 

2.10   集体代码所有权

任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

 

2.11   持续集成

代码完成后数小时，便开始做集成。将代码发布集成到当前的项目中去。运行所有的测试用例。

 

2.12   编码规范

开发团队必须统一采用编码规范。

 

2.13   问题

XP的12个实践是什么？

简单设计，每周40小时工作时间，持续集成，测试，设计，配对编程，现场客户，编码规范，集体代码所有权，精炼，暗喻，小的发布版本。

 

 

 

 

 

3.     极限编程过程

 

 

 

 

4.     XP的策略

4.1      管理策略

解释给最高决策层听。

管理策略 – 圆桌会议

 

4.2      XP管理中的角色

a.     项目经理：直接面向客户，组建团队，获取资源，管理团队及处理问题。

b.     跟踪者：提醒团队的工作必须与需求相符；该角色应该是由项目组成员兼职的。

c.     XP专家：帮助团队使用与理解XP方法，指导团队，帮助团队的工作保持在可跟踪范围内。

d.     视团队规模而定，以上三个角色可以是一个或者多个人。

 

4.3      灵活策略

a.     开放的工作环境。

b.     办公桌位于办公室的中央。

c.     办公区的四周有很多小的办公室。

d.     屋子给人的感觉很不错。

 

4.4      计划策略

a.     只制订一个计划针对于下个版本。

b.     可行的责任。

c.     估算出每个成员的职责。

d.     在计划中区分出优先级。

 

4.5      计划：用户平时的工作流水（User Stories）

a.     必须由真正的用户来写

b.     比之真正的需求说明书要简单的多。而且里面不附带任何技术方面的东西。

c.     对用户来说最最核心的需求要先被开发出来。

d.     流水模板

e. 迭代：预估每个流水的实现时间为1到3周；根据流水的重要性来排出次序；根据流水的复杂程序把每次迭代时间控制在1到3周。

f. 版本：这些版本都是开发团队重复地发布给客户去验收测试的。在每次迭代结束后发布；一个可运行的集成系统。

 

4.6      迭代细分

a.     每个迭代都被细分为一个流水的若干个代码实现的任务。

b.     每个代码实现的任务在1到3天内完成。

c.     每个结对编程小组选择一个或多个任务。

d.     每个小组开始设计测试用例然后逐步去实现。

 

4.7      XP计划概述

 

4.8      设计策略 – 规则

a.     采用最简单的方法去实现。一个简单的系统更容易理解和维护。

b.     采用CRC Card。Class Responsibilities and Collaboration Card。设计系统的架构。让整个团队参与设计。每个CRC Card描述一个个体对象。

c.     选择一个系统架构。

d.     建立一个架构核心解决方案来规避风险。

e.     不要过早的加上一些功能。其实用户使用最多的也只有系统中的10%的功能。所以你只需要专注于你今天的事情。

f.     精简：随时随地的准备以更简单的解决方法去替换复杂的。

设计规则小结：使每件事情尽量简单清晰；精简；紧跟计划。

 

4.9      开发策略

a.     代码的集体所有权：让每个人的代码共享给开发组。

b.     编码规范。

c.     编码之前先写测试用例。

d.     持续集成。

e.     每周40小时工作时间。

f.     结对编程：所有的代码都是同两人肩并肩完成的；编码人员操作键盘；观察人员在一旁指出缺陷并思考策略；两人角色互换。

结对编程的优势：两个大脑总比一个强；两人解决问题的思路肯定更开阔；可供选择的设计增多；代码质量更高；至少有两个人知道系统的各个部分的细节；对项目组的新人而言是一种更有效的学习机制；双倍的压力。

    开发策略小结：编码之前写测试用例；代码集体所有权；编码规范；持续集成；结对编程；每周40小时工作时间。

 

4.10   测试策略

a.     单元测试。开发人员负责自己的单元测试用例开发。

b.     集成测试。所有之前跑通的单元测试用例全部重跑一遍以检验整个系统可以运行。

c.     代码集成。

d.     验收测试。对照用户工作流水来做验收测试；黑盒测试。

测试策略小结：

 

4.11   客户

a.     实用性强的客户。现场客户。

b.     义务。写流水；定义流水优先级；定义各版本的范围与发布时间。

 

4.12   客户与程序员角色

a.     客户决定“你得到什么”以及：系统的功能范围；系统各部分的优先级；各版本应包含的内容；各版本的发布日期

b.     程序员决定“需要什么成本”以及：新增一个功能的时间预估；程序员解释涉及技术的顺序，但最终决定权在客户；团队如何工作；每个迭代的详细进度

 

 

 

 

5.     极限编程vs. CMMI

5.1      XP的优势

a.     更适于需求与功能的变化。

b.     小的开发团队。

c.     客户与项目经理决定输入。

d.     易测性。

e.     XP是根据面向对象编程思想设计的。

 

5.2      采用XP

a.     综合各家技术之所长。

b.     逐步采用。选择项目中最糟糕的问题，应用XP中相应的技术去解决。

c.     必须经常回头整理工作的各个方面。

d.     确定合同的范围。

 

5.3      对XP普遍的误解

a.     不写设计文档。

b.     没有设计。

c.     XP是很简单的。

d.     XP是不稳定的。

 

5.4      CMMI之于XP

a.     很多CMM/CMMI中的PA是XP中没有涉及或只是部分涉及到的。即使没有被明确的指出来，XP在没有管理及其他支持的情况下也是不能生存的。

b.     比较公正的说法，XP专注于技术层面而CMM/CMMI更关注项目管理层面的事。

 

5.5      问题

XP与CMMI具有什么样的关系？

XP与CMM没有冲突。而在实践中，两者冲突比较明显。
以需求为例：CMM要求有方法论得到文档化的需求。
XP重视迭代，现场用户快速反馈。用户故事+程序反映需求。
以计划为例：CMM要求有全面的开发计划，工期，工作量，项目规模，CCR等要作出估算。
而且估算要有依据，而XP中没有如此要求，相反采用快速简单计划的方式来进行。

最根本的关键还在于两者对工程师的态度上。
XP鼓励工程师自由发挥。
而CMM要求工程师根据既定的方法论，使用指定的工具，完成指定格式的工作产品，并且接受监督。
所以XP工程师往往难于接受CMM的各项规定。
而CMM组织也不会全盘采用XP。完全附合CMM的XP是违背XP原旨的XP。不值的这样做。