极限编程XP- 极限编程入门-20210905
2021-09-10 14:22:55 7 举报AI智能生成
坚持一日一思维导图，加油！ 近期钻研主题：敏捷 参考链接：https://www.scrumcn.com/agile/xp.html 最后，走过路过点个小赞 👍 ，谢谢！
作者其他创作
大纲/内容
极限编程的4个价值
沟通
一个软件系统的基本任务之一
与系统的开发者交流以明确系统的具体需求
目标是向所有开发人员提供一个对于系统的共享的视角，
而这一视角又是与系统的最终用户的视角相吻合的
而这一视角又是与系统的最终用户的视角相吻合的
鼓励经常性的口头交流与回馈
简单
从最简单的解决方式入手
通过不断重构达到更好的结果
只关注于对当前的需求来进行设计、编码，
而不去理会明天、下周或者下个月会出现的需求
而不去理会明天、下周或者下个月会出现的需求
将来的需求在他们还没提出之前是很可能发生变化
设计与代码上的简化可以提高交流的质量
反馈
反馈越快越好
“反馈”和系统开发的
很多不同方面相关联
很多不同方面相关联
来自系统的反馈
单元测试
直观的得到经过修改后系统的状态
来自客户的反馈
功能性测试
客户还有测试人员编写
得知当前系统的状态
计划2、3个礼拜进行一次
客户可以非常容易的了解、掌控开发的进度
来自小组的反馈
客户带着新需求来参加项目计划会议
小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户
反馈是与“交流”、“简单”这两条价值紧密联系的
沟通系统中的缺陷
编写单元测试
简单的证明某一段代码存在问题
用户以定义好的功能需求为依据，对系统进行周期性的测试
“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”
Kent Beck
勇气
“只为今天的需求设计以及编码，
不要考虑明天”
不要考虑明天”
避免陷入设计的泥潭、而
在其他问题上花费了太多不必要的精力
在其他问题上花费了太多不必要的精力
在需要重构他们的代码时能感到舒适
重新审查现有系统并完善它
以后出现的变化需求更容易被实现
了解什么时候应该完全丢弃现有的代码
花了一整天的时间纠缠于自己设计和代码中的
一个复杂的难题却无所得
一个复杂的难题却无所得
第二天以一个全新而清醒的角度来考虑
在半小时内就轻松解决
极限编程的5个原则
快速反馈
反馈及时、迅速
客户
在整个开发过程中及时给出反馈意见
在需要的时候能够掌控系统的开发方向
单元测试
同样对贯彻反馈原则起到作用
假设简单
任何问题都可以”极度简单”地解决
传统的系统开发方法
考虑未来的变化
考虑代码的可重用性
极限编程拒绝这样做
增量变化
罗马不是一天建成
比如说
每三个星期发布一个包含小变化的新版本
一小步一小步前进的
拥抱变化
不要对变化采取反抗的态度，而应该拥抱它们
比如，在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。
作为程序员，必须拥抱这些变化，
并且拟定计划使得下一个阶段的产品能够满足新的需求
作为程序员，必须拥抱这些变化，
并且拟定计划使得下一个阶段的产品能够满足新的需求
高质量的工作
四个软件开发的变量
范围
时间
成本
质量
只有质量不可妥协
参考链接
https://www.scrumcn.com/agile/xp.html
极限编程
极限编程
Extreme programming
缩写为XP
一种软件工程方法学
不同
更强调可适应性而不是可预测性
创始者
肯特·贝克、沃德·坎宁安
罗恩·杰弗里斯
《极限编程解析》
极限编程的目标
降低因需求变更而带来的成本
系统需求是在项目开发的开始阶段就确定下来
项目开发进入到之后的阶段时出现的需求变更将导致开发成本急速增加，而这样的需求变更在一些发展极快的领域中是不可避免的
通过引入基本价值、原则、方法等概念
降低变更成本的目的
极限编程的12个核心实践
短交付周期
和Scrum一样采用迭代的交付方式
每个迭代1-3周时间
迭代结束
团队交付可运行的，经过测试的功能
这些功能可以马上投入使用
计划游戏
两个问题
预测在交付日期前可以完成多少工作
现在和下一步该做些什么
不断的回答这两个问题
针对两个问题两个相应过程
软件发布计划（ReleasePlanning）
据开发成本、风险和每个需求的重要性，制订一个大致的项目计划
最初的项目计划没有必要（也没有可能）非常准确
周期开发计划（IterationPlanning）
开发过程中
有很多阶段计划
比如每三个星期一个计划
在某个周期对系统进行内部的重整和优化（代码和设计）
某个周期增加了新功能
会在一个周期内同时做两方面的工作
有利有弊
好处
客户可以马上知道
完成了哪些
做出来的东西是否合用
面还要做些什么或改进什么等
坏处
看到做出来的东西，可能会很不满意甚至中止合同
为了及早发现问题、解决问题
结对编程
两个人坐在一台电脑前一起完成
一个程序员控制电脑并且主要考虑编码细节
另外一个人主要关注整体结构
不断的对第一个程序员写的代码进行评审
结对不是固定的
可持续的节奏
长期维持的速度努力工作
保存精力
把项目看作是马拉松长跑
而不是全速短跑
代码集体所有
每个人都对所有的代码负责
每个人都可以更改代码的任意部分
结队程序设计对这一实践贡献良多
在不同的结队中工作
所有的程序员都能看到完全的代码
编码规范
所有人都遵循一个统一的编程标准
所有的代码看起来好像是一个人写的
简单设计
没有那种传统开发模式中一次性的、针对所有需求的总体设计
设计过程几乎一直贯穿着整个项目开发
从制订项目的计划
到制订每个开发周期（Iteration）的计划
到针对每个需求模块的简捷设计
到设计的复核
以及一直不间断的设计重整和优化
整个设计过程是个螺旋式的、不断前进和发展的过程
测试驱动开发
重构
系统隐喻
持续集成
XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作
现场客户
“客户”
不是为系统付帐的人
而是真正使用该系统的人
客户
时刻在现场解决问题
编写故事
验收测试
更频繁的交流和讨论
职业：本科
0 条评论
下一页
