本文地址: http://www.cnblogs.com/raol/archive/2013/04/14/estimates.html
本书的目标：帮助读者从制定可接受的计划到优秀的计划。
本书的大纲：
一、阐述规划为什么重要以及敏捷估算的目标？（1,2,3）
二、阐述估算的一个重要原则：规模和时间长度的估算应该独立。（4,5,6,7,8）
三、时刻注意判断Story的价值。（9,10,11,12）
四、阐述怎么安排项目时间进度。（13,14,15,16,17,18 ）
五、跟踪和交流。（ 19,20,21）
五、与传统方法进行对照。（22）
六、案例。（23）
一、阐述规划为什么重要以及敏捷估算的目标？（1,2,3）
减少风险
降低不确定性
提供更好的决策支持
建立信任
传递信息
基于功能规划而不是基于活动。
活动不会提前完成
延误传递
多任务延迟
不排优先级
忽视了不确定性
估算当成承诺，估算是可能性
作为一个整体工作
按迭代周期工作
每次迭代交付成果
关注业务优先级
检查与调整
编写用户故事是可以更快的估算价值点
规划方法 更多的是你要了解什么而不是对产品做什么规划。
规划层次
满意条件（项目的Done准则）
二、阐述估算的一个重要原则：规模的估算和任务时间长度的估算应该独立。（4,5,6,7,8）
故事点的估算--故事点是相对的。
理想日进行估算：
所估计的工作将是你唯一需要处理的事情。
你所需要的东西都已经准备好。
不会被打断。
以理想日做出的估算会随开发人员的熟练程度的改变而改变， 故事点不会。
用理想日估计的时候更容易会考虑故事的每项任务，而不是相对的去考虑。
三、时刻注意判断Story的价值。（9,10,11,12）
根据业务价值判断优先级，那么什么是业务价值？考虑这四个因素。
或得这些功能带来的经济价值。
开发新功能所需的成本。
开发新功能所需要的学习和知识的量及重要性。
产品的知识（目标）
项目的知识（方法）
所减少的风险。
进度，成本，功能
提高效率，一些可以考虑的地方。
任何需要或者在公司成长后需要很长时间的事情。
部门之间更好的集成或交流。
降低人员的更替。
对新雇员更短的培训时间。
综合多个过程。
任何可以提高效率或者减少返工的工作。
将来的金额推回现值的过程称为贴现。贴现的利率称为机会成本。
客户满意度的Kano模型
必须的
线性的（越多越好）
惊喜的（未被发现的需求）
用户故事的分割
按数据边界
按操作边界
去除横切考虑--比如登陆功能
不要把故事分解成任务
四、阐述怎么安排项目时间进度和监督。（13,14,15,16,17,18 & 19,20,21）
发布计划的必要性，看清走到了那里， 不要感觉无止境的一个接一个。
迭代规划
分解任务
讨论设计，不过没必要讨论到画出UML图（画出草图）。
没法估算的任务要设立spike任务。
迭代内的bug口述，迭代外的bug和story平级。
迭代结束是重新评估优先级
故事点和任务估算有关系吗？
迭代长度考虑的因素
正在处理的发布的时间的总长度。（一般需要4-5次的迭代才能从中受益）
不确定性的多少。（不确定性越多，迭代时间越短）
或得反馈的难易程度。
优先级可以保持多久不变。
不用外部反馈自行工作的意愿。
迭代系统的开销。
紧迫感。
速率的估算
采用历史值
设计的技术，领域，小组，工具，环境。
进行一次迭代
做出预测
分解成任务，估算每个人可以花在迭代中的时间知道足够的任务填满迭代中的小时数。
建立缓冲区（项目未开始人员未到的估算）参考动态系统软件开发
功能缓冲--我们会提供这些功能还可能会提供哪些功能的一部分。
进度缓冲
五、与传统方法进行对照。（22）
六、案例。（23）
故事的价值点：经济价值，代价，创新/知识，风险。
利用90%的原则说明为什么不制定完美的计划。
分析了敏捷开发过程如何减少目标的不确定性（我们要构建什么？）和方法的不确定性（如何构建？）。减少不确定性，早动手。