解析极限编程xp
2015-03-14 15:50
239 查看
1. 将素材分成点 开发时间=素材点X速度因子
挑选两个素材测试开发时间和速度因子
第一次迭代中完成31个素材点,在下一次迭代计划中应该有31个素材点
通过速度反馈推算的团队开发速度
在一次迭代中任务没有分配完,那么从本次迭代中减去,反之索取跟多任务
迭代中期任务没有完成一半数,重新分配任务保证完成否则需告知客户指出剩余任务的优先级
2. 如果多于一个动机去改变一个类,那么就是多于一个职责
对扩展开发,对修改封闭,可以增加模块,不可修改源码
3. 出入现金流、利率、 失败率
放弃选择 :去除某些东西,选择所需投资量
转换选择:改变项目方向
延期选择:等形势明了后投资,估算现在与延期后的成本差
增长选择:某一市场看来马上要腾飞
4. 成本、时间、质量、范围
钱多点可以促进工作,但时间太短钱无法解决。时间长能够帮助提高质量扩大范围,时间太多也会使质量受损。
开始的时候,需求从来都是不清楚的,客户不能来明确告诉你他们的需要什么,
从第一个版本中看到第二个版本中他们需要的东西。
5. 编码、测试、倾听、设计
编写你能想到的每一个不能立即运行的测试。
在编码、测试、倾听过程中产生好的设计
6. 实践
(1) 计划:
a业务人员
范围,将问题解决到什么程度
优先级,哪个要先业务人员比较清楚
版本组成,要完成多少业务功能
发布日期,造成很大的影响的重要日期
b开发人员
估算,实现一种功能的时间
后果,有些业务策略只有了解到技术后果后才能决策
过程,
日程计划,一个版本内完成哪些任务
(2) 设计
能够运作测试,没有重复逻辑,尽可能少的类别和方法
(3) 开发
重构,结对编程,集体所有权,持续集成,每周工作40 小时
现场客户,编码标准
7.管理策略
接受职责:管理人员的任务是强调要做的事二不是布置工作
优质工作:之间建立信任
递增更改:管理人员要自始至终的提供指导
轻装上阵:管理人员不应加强太多系统开心,如全体人员会议、进度报告
诚实的度量:管理人员的度量标准精确度,如你手上有分钟就不要试图用秒计算
Leader:
充当开发伙伴,一起完成技术任务,鼓励重构,帮助程序员测试、格式、重构,向上层管理人员解释过程,跟踪任务搜集测量数据,干预(我不知道我怎么把项目弄成这样,但现在我必须怎样怎样)
8.计划策略
制定阶段所需的计划,负责实现的人进行估算
尽可能的将最有价值的功能投入生产,产品真正的客户、目标群体、销售人员
(1) 探索阶段
分割任务/组合任务估算某个任务无法在几天内完成要分割,任务只需一个小时要组合任务
(2) 承诺阶段
程序员估算自己的负载因子,如果在最近三次迭代中完成了6、8、7个理想天数任务,那么这就是你因该承担的大约数目。
(3) 指导阶段
9. 开发策略
(1) 持续集成(不超过一天)
(2) 集体所有权
复杂代码不会生存很长时间,每个人都习惯查看代码很快会被发现
(3) 结对编程(各个组队之间换)
10. 设计策略
沟通、简单(尽量少的类、方法、设计意图明确)、反馈、勇气
从一个测试开始,知到何时完成,设计并实现通过测试,进行重构
11.测试策略
如果接口不清楚,如果你想到代码不像理想那样运行,如果你发现某个问题,如果你打算重构某些代码不确定它会有什么样的行为
忌讳:不做规划、无客户参与、“编码并修复”作为生命周期
挑选两个素材测试开发时间和速度因子
第一次迭代中完成31个素材点,在下一次迭代计划中应该有31个素材点
通过速度反馈推算的团队开发速度
在一次迭代中任务没有分配完,那么从本次迭代中减去,反之索取跟多任务
迭代中期任务没有完成一半数,重新分配任务保证完成否则需告知客户指出剩余任务的优先级
2. 如果多于一个动机去改变一个类,那么就是多于一个职责
对扩展开发,对修改封闭,可以增加模块,不可修改源码
3. 出入现金流、利率、 失败率
放弃选择 :去除某些东西,选择所需投资量
转换选择:改变项目方向
延期选择:等形势明了后投资,估算现在与延期后的成本差
增长选择:某一市场看来马上要腾飞
4. 成本、时间、质量、范围
钱多点可以促进工作,但时间太短钱无法解决。时间长能够帮助提高质量扩大范围,时间太多也会使质量受损。
开始的时候,需求从来都是不清楚的,客户不能来明确告诉你他们的需要什么,
从第一个版本中看到第二个版本中他们需要的东西。
5. 编码、测试、倾听、设计
编写你能想到的每一个不能立即运行的测试。
在编码、测试、倾听过程中产生好的设计
6. 实践
(1) 计划:
a业务人员
范围,将问题解决到什么程度
优先级,哪个要先业务人员比较清楚
版本组成,要完成多少业务功能
发布日期,造成很大的影响的重要日期
b开发人员
估算,实现一种功能的时间
后果,有些业务策略只有了解到技术后果后才能决策
过程,
日程计划,一个版本内完成哪些任务
(2) 设计
能够运作测试,没有重复逻辑,尽可能少的类别和方法
(3) 开发
重构,结对编程,集体所有权,持续集成,每周工作40 小时
现场客户,编码标准
7.管理策略
接受职责:管理人员的任务是强调要做的事二不是布置工作
优质工作:之间建立信任
递增更改:管理人员要自始至终的提供指导
轻装上阵:管理人员不应加强太多系统开心,如全体人员会议、进度报告
诚实的度量:管理人员的度量标准精确度,如你手上有分钟就不要试图用秒计算
Leader:
充当开发伙伴,一起完成技术任务,鼓励重构,帮助程序员测试、格式、重构,向上层管理人员解释过程,跟踪任务搜集测量数据,干预(我不知道我怎么把项目弄成这样,但现在我必须怎样怎样)
8.计划策略
制定阶段所需的计划,负责实现的人进行估算
尽可能的将最有价值的功能投入生产,产品真正的客户、目标群体、销售人员
(1) 探索阶段
分割任务/组合任务估算某个任务无法在几天内完成要分割,任务只需一个小时要组合任务
(2) 承诺阶段
程序员估算自己的负载因子,如果在最近三次迭代中完成了6、8、7个理想天数任务,那么这就是你因该承担的大约数目。
(3) 指导阶段
9. 开发策略
(1) 持续集成(不超过一天)
(2) 集体所有权
复杂代码不会生存很长时间,每个人都习惯查看代码很快会被发现
(3) 结对编程(各个组队之间换)
10. 设计策略
沟通、简单(尽量少的类、方法、设计意图明确)、反馈、勇气
从一个测试开始,知到何时完成,设计并实现通过测试,进行重构
11.测试策略
如果接口不清楚,如果你想到代码不像理想那样运行,如果你发现某个问题,如果你打算重构某些代码不确定它会有什么样的行为
忌讳:不做规划、无客户参与、“编码并修复”作为生命周期
相关文章推荐
- Java极限编程 XP
- XP极限编程
- 敏捷开发之道(二)极限编程XP
- 什么是Extreme Programming(极限编程,简称XP)
- Scrum与XP极限编程的不同之处
- [XA]我们为什么不用XP(eXtreme Programming)极限编程?
- XP极限编程
- 重构的必然性 ---一个阶乘容器 + 测试驱动开发 +极限(XP)编程
- 极限编程XP的核心实践是什么?
- XP极限编程
- 什么是xp极限编程
- XP极限编程
- Java程序员的推荐阅读书籍之一《解析极限编程 拥抱变化》
- 闲话XP极限编程之每周工作40小时
- 解析极限编程--拥抱变化(第二版)读书笔记
- 谈谈极限编程XP
- 极限编程立方体 —— XP程序员的一天(XP Programmer's Cube - A Day in the Life)
- 极限编程XP
- XP--极限编程
- 敏捷开发之道(三)极限编程XP续