软件开发方法–XP(eXtreme Programming)编程讲义
本文主要讨论的主题:
®什么是XP方法？
®发展沿革
®主要思想
®项目应用案例？
什么是XP方法？
®eXtreme Programming
®XP 是以开发符合变化的客户需求的软件为目标而产生的一种方法， 它的成功得益于它对客户满意度的特别强调，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。
®是一种经历过很多实践考验的软件开发方法. 已经被成功的应用在许多大型的公司，如：Bayeris che
Landesbank , Credit Swis s Life,DaimlerChrysler, First Union National
Bank, Ford Motor Company and UBS.
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.
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.
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.
The Rules and Practices
®Planning
®Designing
®Coding
®Testing
Planning
®
Release planning creates the schedule.
® Make frequent
small releases.
® The
Project Velocity is measured.
® The project is divided into
iterations.
®
Iteration planning starts each iteration.
® A
stand-up meeting starts each day.
®
Fix XP when it breaks.
User stories
®类似于use cases但不一样
®用于估计
release planning meeting的时间
®替代详细的用户需求规格说明书
®由用户书写，类似于用户“场景”，但不局限于界面的描述
®没有技术术语
®能够成为验收测试的依据
Release planning
®通过召开 release planning meeting 来制订一份发布计划
®发布计划详细描述用户所要求的各版本要求，这为后面的迭代计划打基础
small releases
®经常向客户发布系统的迭代版本
®在 release planning meeting上确定哪些功能单元对用户业务有重要影响并可在早期加入到系统中
®越晚向用户介绍系统的重要特征，开发队伍所获得的“搞定”系统的时间就越短。
Project Velocity
®项目周转时间是衡量项目工作进度速度的值。
®“负载因子”近期被引进用于项目周期的测量
Iterations
®迭代式开发增加了开发过程的敏捷性
®将总体进度划分为一系列长度为1-3周的小的迭代过程. 迭代周期固定且一致，成为项目的“心跳” 。
Iteration planning
®在每个迭代的开始召集迭代计划会议，明确本次迭代任务
®每次迭代1-3周长
®由用户在
User stories中确定最有价值的特征作为本次迭代的目标
®上次迭代时没通过验收测试的特征应当加入本次迭代
Move people around
®让所有人多掌握技能，避免知识孤岛和开发瓶颈
®交叉培训，“结对编程”
®并非一个人掌握所有的代码，而是要每个人掌握大多数的代码，所需要的人员可以随时被指派到最需要的地方，实现人员的“负载平衡”
®每次迭代每个人试图做系统新的部分，
Pair
programming 能够保证这种形式
stand-up meeting
®目标：在整个开发组（而非个别开发人员）中进行沟通
®每天早上一次站立会议，主要沟通问题、方案，以集中小组注意力
®避免了策划会议的时间
®daily stand up meeting 不同于一般浪费时间的会议
Fix XP
®一旦破坏了XP流程，就马上更正！
®可根据具体项目制定XP规则，一旦制定就必须执行，直到规则变更
®所有人员都明确知晓规则
Designing
®
Simplicity.
® Choose a
system metaphor.
® Use
CRC cards for design sessions.
® Create
spike solutions to reduce risk.
® No functionality is
added early.
®
Refactor whenever and wherever possible.
Simplicity is the Key
®决不增加没有列入到进度中的功能
®“简单化”其实并不简单
system metaphor
®为系统选择一种metaphor使得开发小组能够为类及方法进行统一的命名.
®命名方式易理解.
®Class, Responsibilities, and Collaboration (CRC)
®CRC cards的最大价值在于引导开发人员摆脱过程模型，精确掌握OO技术
®CRC Cards 允许所有的人参与设计，参与的人越多，就会有更多的好的主意引入
®创建关键问题解决方案，解决关键的技术和设计问题
®大多数 spikes可能都不足以得到保持，有可能被丢弃. 但制作SPIKE的目标降低技术风险；
®一旦技术困难对系统的开发造成了威胁，立即派一对开发人员关注于该问题一至两周，以降低潜在的风险
No functionality is added early
®切记不要实施你认为日后可能有用的额外特征
®只有10% 的额外特征会有用
®只关注目前进度中所要求的内容
Refactor whenever and wherever possible
®随时随地可以对已做过的事重新考虑
®毫不留情地将设计、编码简单化，简单得足够容易理解、修改和扩展
®所有的事只表达一次
®修饰得太好的系统往往到后期赶不上进度要求
Coding
®The customer is
always available.
® Code must be written to agreed
standards.
® Code the
unit test first.
® All production code is
pair programmed.
® Only one pair
integrates code at a time.
® Use
collective code ownership.
® Leave
optimization till last.
® No
overtime.
The customer is always available
®随时能联系客户是XP方法的基本要求之一
®XP的所有阶段都要求客户的强参与
®最好有客户派员直接参与开发组
®把客户“吊住”，并将客户由新手培养成为专家，开发组需要专家
Code must be written to agreed standards
®所有代码必须采用统一标准以便理解
®Smalltalk projects ：
Smalltalk Best Practice
Patterns
Code the unit test first
®创建单元测试能够帮助开发者清醒地意识到什么是真正需要的
®需求是由测试活动明确下来的
All production code is pair programmed
®所有发布的代码都由两个程序员在一台机器上共同开发完成。
®结对编程的最好方式是两人共同坐在显示器前，将键盘和鼠标在两人之间“滑动”，一人考虑所创建的方法（Method），而另一人同时考虑该方法如何在类中得到更好的体现。
®适应结对编程需要时间，必须度过开始面临的尴尬境况
Sequential Integration
每次加入一个模块做集成
®开发人员应不断地将代码集成到代码库中，几小时一次，绝不超过1天
®每个人需要在最后的版本上工作
®持续集成能够在早期避免或发现一些兼容性问题。“现在付钱还是以后付更多的钱？”
®“集体拥有代码”鼓励每个人对项目的所有部分提出新想法
®任何开发人员都可改变任何代码以增加功能、修改错误
®没有人会成为变更的瓶颈
Leave optimization till last
®在项目快结束之前不要去优化
®永远不要试图猜测系统的瓶颈在哪里，去度量它、让系统动起来、修正系统、去让系统变的更快！