最近在看《敏捷软件开发实践：估算与规划》，结合自己在工作的中的实践，浅谈一点自己的想法和总结。
总的来说敏捷估算与规划更关注纵向的特性，而非横向的活动。根据“大小/速度=时间”以及“故事点/实际时间=速度”的关系，敏捷项目规划能灵活地结合时间、速度、大小这些变量来规划和调整。产品愿景按照优先级和速率梳理出分层的发布计划或者迭代计划，再按照优先级进入迭代开发。敏捷估算与计划更强调集体合作和响应变化。敏捷计划是具有欺骗性的。在某个层面上，它相当容易——建议一些故事卡片，确定它们的优先级，把它们分配到不同的发布迭代周期，然后添加其他的细节来获得下一轮的迭代计划。
计划对任何敏捷开发项目都是不可缺少的组成部分。首先，敏捷开发小组会进行大量的计划活动，但这些活动被更为均衡地分布于项目的整个开发过程。其次，敏捷开发小组会直接面对不确定性这一被许多非敏捷开发小组所忽视的关键因素。计划重要吗？——当然重要。随着知识的获取和不确定性的降低调整计划重要吗？——当然重要。
敏捷开发方法强调实际交付价值而不是做出一些非凡的但是无法实现计划和承诺。获得适应变化的应用环境的灵活性，与绝对地遵守原始计划——是互相矛盾的。
减少目标不确定性（我们到底要构建什么）和方法不确定性（我们如何构建它）。
计划是基于我们在某个特定时间点上所知道的东西做出的，而不确定性则是对我们所不知道的事情——对目标或者方法——的另一种表述。
1.规划的目的
好的规划过程通过以下活动来支持这种对价值的探求：
♦减少风险（估算能揭示项目中存在的部分黑暗角落，提高对项目中的各项风险认识）
♦降低不确定性（持续的规划能逐步明确项目中的某些不确定性）
♦提供更好的决策支持（项目规划时所作出的许多决策都是折中后的决定，我们经常在功能特性与投入的精力、成本和时间之间进行类似的折中，要做出这些决策，就需要对成本和收益进行估算。）
♦建立信任（频繁地、可靠地交付承诺的功能可以在产品的开发人员和产品的客户之间建立信任。）
♦传递信息（计划可以传递针对项目的期待，并且描述完成项目的可能路径之一。）
2.规划失败的原因
♦基于活动而不是基于特性进行计划（特性才是客户价值的计量单位。基于活动的计划导致超期的原因包括：活动不会提前完成，延误沿着计划表向下传递，活动不是互相独立的）
♦多任务处理导致更多的延迟
♦不按优先级开发特性
♦忽视了不确定性（传统规划方法的第四个缺点是无法意识到不确定性的存在。反映这种不确定性的方法之一是将结束时间表述为一个时间范围。随着项目的进展，项目的不确定性和风险会逐渐减少，估算就可以进一步细化，变得更加精准。）
♦把估算当作承诺（每个估算都包含了一定的可能性，他表示该特定工作在估算的时间长度内完成的可能性，并不能当成承诺。）
3.敏捷规划方法
规划更多的是关于你要学习什么，而不是它（产品）最终是什么。当我们承认在某种程度上不知道结果，也不可能提前知道结果的时候，规划就成为一个设定并修正目标的过程，而这些目标指引我们实现一个更长远的目标。
（1）规划的不同层次
设定和修正目标的时候，重要的是记住我们无法看到地平线以外的东西，而且当我们试图规划的距离超出视线范围越远，计划的准确性降低得就越迅速。
（2）满意条件驱动发布规划和迭代规划
4.使用故事点估算
（1）故事点是相对
故事点是用于表达用户故事、功能或其他工作的总体规模的度量单位，我们给每个故事分配一个点值。分配的原始点值本身并不重要，重要的是值得相对大小。故事点估计是对开发该功能所需的工作量、开发工作的复杂性以及蕴藏的风险等方面的综合。
两种常用的故事点估计：
一、以将要处理的用户故事中，从您认为最小的那些故事里面选择一个，然后设定它被估计1个故事点。
二、选择一个基本处于中等的用户故事，然后给它分配一个大致处于你的取值范围中间的点值。
（2）速度 velocity
要理解为什么没有单位的故事点估计有可能会有效，就必须介绍速度这个概念。速度是对开发小组的进度率的度量。可以通过计算小组在一次迭代中完成的用户故事点数的总和来得到速度。
敏捷估计与规划的一个关键原则是先估计出规模然后推算出持续时间。
速度修正估计误差
随着开发小组在项目的用户故事上取得进展，他们的速度在最初几次迭代中就会显示出来。基于故事点的估计方法的美妙之处就在于对速度的使用使得规划误差可以自我修正。
5.使用理想日估计
理想时间（ideal time）是某件事在剔除了所有外围活动之后所需要的时间。
耗用时间（elapsed time）是时钟（也许是日历）上显示出流逝掉的时间。
两种对持续时间的度量分别有自己的用途。
用理想时间而不是耗用时间来预测某件事的持续时间总是更准确，而且要容易得多。
当不考虑机构性开销的时候，理想日可以被看作另一种对规模进行估计的方法，就像故事点一样。可以用速度把以理想日的数量表示的规模估计转换成对持续时间的估计。如果选择使用理想日进行估计，就应该为每个用户故事分配一个总的估计值。
6.估计方法
收益边界渐减法则：即回报的增长幅度随着投入的增加而减小
（1）共同估计
最佳的估计是由包括将要做此工作的人在内的小组合作得到的。原因一：敏捷开发中，往往不知道一项工作将有特定的哪个人来完成。原因二：某个人的估计其他人可能有别的考虑。
（2）估计的尺度
●1、2、3、5、8 斐波那契数列
●1、2、4、8 每一个数都是前一个的两倍
0有可能会作为估计范围中的一个有效值，如果我们想把所有功能都保持在一个10倍的范围内，那么极小的功能分配非零值会限制最大功能的规模。且如果工作确实更接近于0而不是1，开发小组可能也不希望在计算速度时考虑完成这些功能的贡献。
离最近几次迭代更远的用户故事或者其他对象可以被当做史诗用户故事或主题。为了估计这些大对象，可以在后面添加大的数字：
●1、2、3、5、8、13、20、40、100
（3）得到估计值的方法
●专家意见
●类比
●分解
（4）规划扑克
更小规模的会议
开发小组需要在两个不同时期打规划扑克。首先，在项目正式启动前或者在它的第一次迭代中。对用户故事的初始合集进行估计需要开发小组进行两到三次1-3个小时的会议。其次，小组需要在开发过程中对在迭代中发现的新用户故事进行估计。
规划扑克会有效的原因：首先，规划扑克做估计时把多条专家意见放在了一起，形成了跨功能的小组，比任何单独的个人更适合做估计。其次，规划扑克期间会进行活跃的对话，规划者会被要求证明自己的估计的正确性。第三，对个人估计的平均可以引向更好的结果，对估计进行团体讨论也可以得到同样的效果。最后，规划扑克起作用也因为它很有趣。
7.重估的情况
始终牢记故事点和理想日是对规模的估计，就会发现只需要在我们确信一个用户故事的相对大小发生了变化的时候，才需要重新估计。
8.在故事点和理想人天之间进行选择
选择故事点的优势
●故事点有助于驱动跨功能的行为
●故事点估计不会过期
●故事点是对大小的纯粹度量
●故事点估算通常更快
●我的理想人天不等于你的理想人天
有利于理想人天的考虑因素
♦ 理想人天在团队以外更容易解释
♦ 理想人天估算更容易开始
♦ 理想人天便于预测速度
9.为价值做规划
要建立产品功能（范围）、进度和成本的最佳组合，需要对发布的产品中将要包含的用户故事和主题的成本和价值进行深远的考虑。
（1）确定主题的优先级
即使我们有时间，也很少会有足够的时间来做所有的事。所以要确定优先级。尽管确定优先级的责任由整个开发小组共同承担，但成果由产品所有者享有。估计少量的功能往往是很困难的。我们将单个的用户故事和功能聚集到一些主题中。然后，根据用户故事和主题之间的相对关系，确定它们的优先级，来满足建立发布计划的需求。选择主题的时候应该让它们都能都能分别独立地定义一组对用户或是客户有价值的功能。
确定优先级时的因素：获得这些功能带来的经济价值；开发所需的成本；所产生的学习和知识的量及重要性；减少的风险。
（2）确定经济优先级
收入的来源：新收入、增量收入、留存收入和操作效率
经济指标：金钱的时间价值、净现值、内部收益率、投资回收期、贴现回收期
（3）确定渴望度优先级
阈值功能是产品要成功就必须具备的那些功能。它们常常也称为必需的（must-have）功能。改善阈值功能的性能或者增加阈值功能的数量对客户满意度没有多少影响。
线性功能就是一个处于“越多越好”状态的功能。这些功能称为线性功能的原因是客户满意度与功能的量线性相关。一个这样的功能表现得越好（或者它越多），客户就会觉得越满意。因此，产品价格常常和线性特性相关。
最后，兴奋点和惊喜点是那些提供了很高的满意度，并常可以为产品增加额外价格的那些特性。但是，缺少兴奋点和惊喜点并不会让客户满意度降到中性以下。
实际上，兴奋点和惊喜点也常称为未被了解的需求，因为客户或用户在看到这些特性之前并不知道自己需要它们。
用Kano模型评估主题（依赖问卷调查）
相对权重：另一种方法（依赖于专家判断）
平时工作中，可能调查问卷的方式更广泛一些，对用户进行分类分组，能得到广泛的数据支持。
