软件工程导论---极限编程

极限编程

• 创始者是肯特·贝克(Kent Beck)、沃德·坎宁安( Ward
Cunningham)和罗恩·杰弗里斯(Ron Jeffries),他们在
为克莱斯勒综合报酬系统(Chrysler Comprehensive
Compensation System )(C3) 的薪水册项目工作时提出了极
限编程方法。
• Kent Beck在1996年3月成为C3的项目负责人,开始对项目
的开发方法学进行改善。他写了一本关于这个改善后的方法
学的书,并且于1999年10月将之发行,这就是《解析极限编
程》。

• 极限编程将开发阶段的4个活动(分析、设计、编码和测试)
混合在一起,在全过程中采用迭代增量开发、反馈修正和反
复测试。
在这里插入图片描述

《极限编程解析》(2005第二版出版)阐述了如下的极致编程的哲学思想 :

一种社会性的变化机制

一种开发模式

一种改进的方法

一种协调生产率和人性的尝试

一种软件开发方法

五个准则:

(改善)沟通

• 项目相关人员之间充分的多渠道的的沟通。

(寻求)简单

• 选择最简单的设计和实现来处理客户的需要。

(获得)反馈

• 来自系统的反馈:通过编写单元测试,程序员能够很直观的
得到经过修改后系统的状态。
• 来自客户的反馈:功能性测试是由客户还有测试人员来编写
的。这样的评审一般计划2、3个礼拜进行一次,这样客户可
以非常容易的了解、掌控开发的进度。
• 来自小组的反馈:当客户带着新需求来参加项目计划会议时,
小组可以直接对于实现新需求所需要的时间进行评估然后反
馈给客户。

(富有)勇气

• 面对压力作正确的判断并敢于付诸行动,如尽早地和经常交付功
能的承诺,敢于丢弃设计不良的代码等。

(互相)尊重(最新添加的价值)

• 尊重的价值在极限编程中,团队成员间的互相尊重体现在每
个人保证提交的任何改变不会导致编译无法通过、或者导致
现有的测试case失败、或者以其他方式导致工作延期。
• 团队成员对于他们工作的尊重体现在他们总是坚持追求高质
量,坚持通过重构的手段来为手头的工作找到最好的解决设
计方案。

十二条原则:

简单设计

• 为已定义的功能进行设计,而不是为潜在地未来可能
的功能进行设计。
• 最简单的设计将软件的一个可测试版本交付给用户。
• 创建最佳的可以实现功能的设计。

重构

• 重构是以不改变软件外部行为而改进其内部结构的方
式来修改软件系统的过程。为减少引入错误、减少冗
余、提高性能等目的,随时调整、优化系统的结构。

结对编程

• 所有的程式码都是由两
个人坐在一台电脑前一
起完成的。一个程式设
计师控制电脑并且主要
考虑编码细节。另外一
个人主要关注整体结构,
不断的对第一个程序设
计师写的程序进行评审。
结对编程的好处
 有助于提升代码设计质量;
 研究表明结对生产率比两个单人总和低 15%,
但缺陷数少 15%,考虑修改缺陷工作量和时间
都比初始编程大几倍,所以结对编程总体效率
更高(source: The Economist);
 结对编程能够大幅促进团队能力提升和知识传
播。

代码集体所有

• 项目组中的每个人都可以在任何时候修改其他项目成员的代
码,这就是XP中所定义的代码共享。
• 强调所有的人都对代码负责。如果一个开发人员的代码有错
误,另外一个开发人员也可以进行BUG的修复。 提高了代
码的透明度,增进了团队的合作精神。一定要有严格的配置
管理。

持续集成

• XP实践者将每日集成作为最大
要求,选择每两个小时一次的
频繁编链。
• 冒烟测试

在这里插入图片描述

持续集成的好处

 大幅缩短反馈周期,实时反映产品真实质量状态;
 缺陷在引入的当天就被发现并解决,降低缺陷修改成
本;
 将集成工作分散在平时,通过每天生成可部署的软
件;,避免产品最终集成时爆发大量问题。

要点

坚持自动化是持续集成质量 保障;
 修复失败的构建是团队最高优先级的任务;
 开发人员须先在本地构建成功,才可提交代码到配
置库 ;
 持续集成的状态必须实时可视化显示给所有人;

每周工作40小时

• 程序员在疲劳时无法
保证最高效率。连续
两周加班是绝对不允
许的 。

现场客户

• 客户应该时刻在现场解决问题 。

测试驱动开发

• XP使用两种测试:单元测试和功
能测试。单元测试要求在写代码
之前就开发出相应功能的测试方
法,并且测试应当是自动化的。
代码一完成,它就被立即用有关
测试集加以测试,从而能立即得
到反馈。

策划游戏

• 每三周为一个循环,频繁地更新,按优先级划分任务与技术,
分配stories(一个story定义了一个特殊的功能需求并以一
种简单的方式记录在卡片上),所有的这些就是构成了XP中
的计划。通过结合使用优先级“故事”和技术估算,确定下
一版本的功能

小型发布

• 以小的增量版本经常向客户发布软件。每个版本应该尽可能
的小,而且包含最有商业价值的需求 。
1.4.4.5 极限编程

系统隐喻

• 通过提供类似系统全局的视图来指导系统的开发。
• 例:拼图时,尽管也能够痛苦的完成,但如果有了原图则拼
图非常轻松。原图就类似系统隐喻。

程序设计标准

• 程序员采用一致的编码标准。

误解

敏捷是拯救任何项目的银弹

– 敏捷方法只有运用得当才有效果

敏捷意味着 ad-hoc hacking ,不需要任何文档.

– 敏捷是有严格要求的,也是面向质量的
– 根据沟通的需要产生相应的文档

敏捷只是开发者的问题

– 基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同,
角色, 定价模型, 项目管理等

采用敏捷方法的开发组/项目不需要制定计划

– 敏捷项目需要经常制定计划,但是不需要试图超前制定项目计划,通
常这也是不可能的

敏捷项目的范围可以随时改变

– 变更可以等到下一次迭代开始,当前正在进行中的迭代不能变更

只对小项目适用

– 在中型和大型的项目中一样取得了成功

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

醉卧考场君莫笑

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值