解析极限编程xp

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.测试策略

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

 

忌讳：不做规划、无客户参与、“编码并修复”作为生命周期

转载于:https://www.cnblogs.com/tintindeng/p/4337521.html