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