您的位置:首页 > 编程语言

解析极限编程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.测试策略

如果接口不清楚,如果你想到代码不像理想那样运行,如果你发现某个问题,如果你打算重构某些代码不确定它会有什么样的行为

忌讳:不做规划、无客户参与、“编码并修复”作为生命周期
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: