极限编程介绍

极限编程Extreme Programming
东南大学自动控制系
08001211 许元
2004-12-25
极限编程介绍
极端编程(XP)全名Extreme Programming ，一种轻量级，灵活的方法。 XP 是以开发符合变化的客户需求的软件为目标而产生的一种方法， 它的成功得益于它对客户满意度的特别强调，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。

极限编程介绍
是一种经历过很多实践考验的软件开发方法. 已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank , Credit Swis s Life,DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.

极限编程发展
1990s，Kent Beck and Ward Cunningham together had experienced an approach to software development that made every thing seem simple and more efficient.
March, 1996,  Kent started a project at DaimlerChrysler using new concepts in software development. The result was the Extreme Programming (XP) methodology. What Kent came to realize is that there are four dimensions along which one can improve any software project, which are Communication, Simplicity, Feedback, and Courage. These are the four values sought out by XP programmers.
XP的十二种实践方法
XP的十二种实践方法
制定计划(Planning game)
小版本(Small releases) 
隐喻(Metaphor)
简单设计(Simple design)
测试(Testing)
重构（Refactoring）
成对编程(pair programming) 
集体代码所有权(Collective ownership)
一周40小时 (40-hour week) 
持续集成(Continuous integration)
现场客户(On-site customer)
编码标准(Coding standards) 
XP的十二种实践方法
小版本(Small releases)
经常向客户发布系统的迭代版本
在release planning meeting上确定哪些功能单元对用户业务有重要影响并可在早期加入到系统中
越晚向用户介绍系统的重要特征，开发队伍所获得的“搞定”系统的时间就越短。
<BACK>
成对编程(pair programming) 
所有发布的代码都由两个程序员在一台机器上共同开发完成。
结对编程的最好方式是两人共同坐在显示器前，将键盘和鼠标在两人之间“滑动”，一人考虑所创建的方法（Method），而另一人同时考虑该方法如何在类中得到更好的体现。
适应结对编程需要时间，必须度过开始面临的尴尬境况

结对的好处 
［结对］通常表示两个开发人员共用一台计算机、一台监视器、一个键盘和一个鼠标（我发现两台监视器、两个键盘和两个鼠标更有趣、更高效，但一套设施也可以干得很好）。您和搭档坐在键盘前。一个人驾驶（“驾驶员”），另一个人为他导航（“导航员”或“伙伴”）。 　　如果驾驶员停滞不前或受到挫折或者失去了思路，导航员和驾驶员可以互换角色。实际上，这种角色互换应该经常发生，有时可能每隔几分钟（甚至更频繁）就互换一次。一旦您习惯了这种做法，并且适应了与您结对的特定人员，您就会进入这种流程，很自然地来回互换角色。
<BACK>  
集体代码所有权(Collective ownership)
“集体拥有代码”鼓励每个人对项目的所有部分提出新想法
任何开发人员都可改变任何代码以增加功能、修改错误
没有人会成为变更的瓶颈
集体代码所有权
个人骄傲－＞团队骄傲
防止“罚不责众”，但也要防止“人人有责”变成“无人有则”

<BACK>
制定计划(Planning game)
通过召开 release planning meeting 来制订一份发布计划
发布计划详细描述用户所要求的各版本要求，这为后面的迭代计划打基础
计划要十分简单，并提供非常好的信息和极好的操纵控制 ；在XP中没有“百分之九十完成”：一个特性故事要么完成了，要么没有完成。
<BACK>

隐喻(Metaphor)
为系统选择一种metaphor使得开发小组能够为类及方法进行统一的命名.
命名方式易理解.
<BACK>
简单设计(Simple design)
决不增加没有列入到进度中的功能
“简单化”其实并不简单
<BACK>
测试(Testing)
Code the unit test first
创建单元测试能够帮助开发者清醒地意识到什么是真正需要的
需求是由测试活动明确下来的

<BACK>

重构（Refactoring）
随时随地可以对已做过的事重新考虑
毫不留情地将设计、编码简单化，简单得足够容易理解、修改和扩展
所有的事只表达一次
修饰得太好的系统往往到后期赶不上进度要求
<BACK>

持续集成(Continuous integration)
开发人员应不断地将代码集成到代码库中，几小时一次，绝不超过1天
每个人需要在最后的版本上工作
持续集成能够在早期避免或发现一些兼容性问题。“现在付钱还是以后付更多的钱？”
<BACK>
现场客户(On-site customer)
随时能联系客户是XP方法的基本要求之一
XP的所有阶段都要求客户的强参与
最好有客户派员直接参与开发组
把客户“吊住”，并将客户由新手培养成为专家，开发组需要专家
<BACK>

编码标准(Coding standards) 
XP团队遵循一个公共的编码标准，因此系统中所有的代码看上去都像出自单独一个——非常有能力的——人之手。这个标准的规定并不重要：重要的是要让所有的代码看上去很相似，用来支持集体代码所有权。
<BACK>
一周40小时 (40-hour week)
Kent Beck 说他希望“...每天早晨都感到有活力有激情，每天晚上都感到疲惫而满足。”一周 40 小时工作可以让您做到这一点。确切的小时数并不重要，重要的是原则。长时间地持续工作会扼杀工作绩效。疲劳的开发人员会犯更多错误，从长期来说，将比按“正常”时间表进行的开发慢得多。即使开发人员可以在长时间很好工作，这也不意味着他们应该这样。最终他们会厌倦，会离开他们的工作，或者产生影响他们工作绩效的非工作问题。
<BACK>
ＴＨＥ　ＥＮＤ
 相关资料
Extremeprogramming: http://www.extremeprogramming.org/
XPdeveloper: http://http://www.xpdeveloper.com/
Xprogramming: http://www.xprogramming.com/ＴＨＡＮＫ　ＹＯＵ！