《敏捷估计与规划》读书笔记
CH1-1 策划过程比计划书更重要。
CH1-2 必须做计划，但是不必过度投入时间。
CH1-3 对瀑布模型的不确定性锥：
CH1-4 PMI认为的估算偏差率：
初步估算，order of magnitude estimate, 误差范围+75%到-25%；
预算估算，budgetary estimate, 误差范围+25%到-10%；
确定性估算，definitive estimate, 误差范围+10到-5%。
CH1-5 估算是渐进准确的。
CH1-6 项目计划的很多决策都是折中的结果。
CH1-7 plan是文档，是结果，planning是过程。
CH2-1 需求定义了做什么，计划定义了怎么做。需求是用户说了算，计划是开发团队说了算。
需求分析让我们思考做正确的事，策划让我们思考正确的做事。
CH2-2 功能交付了价值，我们在做计划时应该是基于功能，而不是基于活动。
CH2-3 聚焦于遗漏了哪些需求来评价计划，而不是聚焦于遗漏了哪些活动来评价计划。
CH2-4 帕金森定律，任务总是推迟到最后一刻才完成。
CH2-5 同时并行多任务造成了浪费：
CH2-6 应对不确定性的最佳方法就是迭代。
CH2-7 估算不代表承诺。
CH3-1 变化的是价值，计划不是价值，计划是为价值的实现服务的。所以要响应变化！
CH3-2 敏捷开发小组的工作方式：
作为一个整体工作；
短周期迭代；
每次迭代要交付一些成果；
关注业务优先级；
检查和调整；
CH3-3 敏捷开发项目更像是计时赛。
CH3-4 敏捷规划是多层规划的，敏捷规划洋葱圈如下：
CH3-5 在敏捷方法中质量是不可协商的。
CH3-6 验收准则或满意条件是逐层定义的，区分为通用的与专用的。
用户故事的验收标准是专用的，针对某个故事的。
用户故事的DoD是通用的，针对所有故事而言的。
CH4-1 故事点是相对规模，是对工作量，复杂度，风险的综合考量。
CH4-2 初始参考的故事可以是一个你认为的最小的故事，也可以是中等规模的故事。
CH4-3 速度是对开发团队进度率的度量，是一次迭代中完成的故事点数的总和。
CH4-4 对工期进行推理，推算，而不是拍脑袋。
CH5-1 区分理想时间与耗用时间。
CH5-2 管理者与成员要使用时间的相同含义进行对话，不能我说理想时间，你说耗用时间。
CH5-3 橄榄球教练：因为你每场比赛不是很忙，所以我要你同时能参加另外一场冰球比赛！
CH5-4 如果以理想日作为估算的单位，是以谁的理想日来测算呢？高水平，中间水平，低水平？
CH5-5 以总的理想日，而不是实现需求的分角色的理想日代表该需求的规模。
CH6-1 投入时间的回报渐减法则。
CH6-2 把斐波那契序列想象为不同容量的装东西的桶，这样就可以使用就高不就低的原则了。
CH6-3 主题是一组相关的故事。
CH6-4 多种估算方法总和使用最有效。
CH6-5 类比法，三角法，比a大，比c小，就定义为b。
CH6-6 裂解法，把大故事拆小以便于估算。
CH6-7 策划扑克法结合了专家意见、类比和裂解方法。
CH6-8 策划扑克法的目的不是获得一个经得起未来审查的估计，相反，它是通过较小的代价得到一个有价值的估计。
CH6-9 讨论时总会设计到需求的解决方案。
CH6-10 每轮讨论时间限制在2分钟内。
CH6-11 如果分组做了估算，要确保大家对故事点的理解是一致的。可以先在一起估计10-20个故事，再分头估算。
CH6-12 策划扑克法的两个时机：1 初期 2 新增需求时。
CH6-13 应该让最胜任某项任务的人做估算。
CH7-1 每个故事要么完成，要么没有完成，不要计算部分故事的点数。
CH7-2 要么对所有的故事重估，要么都不重估，除非仅仅对某个故事的相对规模有较大的估计偏差。
CH8-1 我是做ABC项目，我是测试人员 VS 我是测试人员，我分配到了ABC项目。
CH8-2 故事点与实现的技术无关，与实现的人无关。
CH9-1 可以对主题划分优先级。
CH9-2 划分优先级需要考虑的主要因素：
业务价值：经济影响；
开发成本：
需要获取的新知识的量与重要性：业务知识与技术知识
减少的风险：
CH9-3 目标不确定性与方法不确定性：
CH9-4 价值-风险矩阵及开发顺序：
CH10-1 预测需求的经济价值是PO的职责。
CH10-2 从新收入，增量收入，留存收入，运行效率四个方面对主题进行经济分析。
CH10-3 经济分析手段只能应用系统级别，主题、史诗的颗粒度都有点小，所以本章的方法仅有理论意义，没有实际价值。
建昊，Mike Cohn,敏捷估计与规划一书中第10章确定经济优先级，没有多少实际价值吧？你见过有哪个公司这么实践的吗？我认为对：
1 项目立项与否可以做分析，对一个项目中的大的子系统可以这么分析，对于小颗粒度的需求实际是没有意义那么分析的。
2 净现值，对于短周期的项目计算净现值有什么实际意义吗？
3 让需求方去计算内部收益率，回收期，贴现回收期不现实，哪个甲方会这么干？
4 感觉这里的经济分析确定优先级方法是传统行业，是大项目的，不适用于软件行业的增量交付的开发。
你的观点如何？
CH11-1 有时候必需的需求部分实现也可以，需求要有，好到什么程度，实际上是下一个层次的需求有先级了。
CH11-2 随着时间的推移，兴奋型需求可能会变为线性需求或是阈值功能。
CH11-3 两个问题，5个刻度帮助划分优先级：
两个问题：
功能存在：如果产品中有这项需求，用户感觉如何？
功能缺失：如果产品中没有项需求，用户感觉如何？
每个问题给出5个刻度：
1）我希望如此；
2）我预期就是这样的；
3）我没有意见；
4）我可以忍受这样；
5）我不希望这样；
CH11-4 汇总对需求优先级调查结果的矩阵：
CH11-5 Karl Wiegert 相对权重法
相对收益：1-9之间，如果有此功能的相对收入大小；
相对惩罚：1-9之间，如果没有此功能的相对损失大小；
总价值：上述两者之和，也可以是加权求和；
价值百分比：每个需求的总价值占总数的%；
估计值：估计的投入多少，故事点或理想日；
成本百分比：每个需求的成本估计值占总成本的%；
优先级：价值百分比/成本百分比
CH12-1 分割故事的方法：
按照数据边界分割故事，区分处理数据的不同子集；
按照操作边界分割，如增删改查；
分割出来复用的需求；
分割非功能性需求；
分割具有不同优先级的子需求；
CH12-2 不要按技术层次分割；
CH12-3 避免在一个故事中增加不必要的变动；
CH12-4 2周的迭代周期中，用户故事的合适颗粒度为2-5天；
CH12-5 太小的故事，比如修复bug，可以组合故事。
CH13-1 典型的发布周期3-6个月。
CH13-2 发布计划时不需要把故事拆分成任务。
CH13-3 发布计划时要先确定DoD。
CH13-4 两种排计划的方式：
日期驱动：定好交付日期，裁剪需求；
功能驱动：定好范围，裁剪工期；
CH13-5 2-4周的迭代周期比较合适。
CH13-6 并不需要在发布策划会议上定义出本发布周期内，每次迭代要开发用户故事，而可以仅仅确定前2-3次迭代的。
CH13-6 发布计划在每次迭代开始时进行更新。
CH14-1 使用卡片讨论是一种更为民主、更为合作化的方法，而不是由一个人控制。
CH14-2 在迭代策划会议上可以不分配任务，而是在迭代中大家领用任务。
CH14-3 发布计划中故事采用故事点估算，迭代计划中的任务采用理想小时（工作量）做估算。
CH14-4 迭代计划的两种方法：速度驱动与承诺驱动。
CH14-5 确定目标速度的常用方法是昨日天气法。
CH14-6 迭代目标并非一定要特别明确。
CH14-7 把用户故事拆分成任务：
1 只包含为此项目增加价值的任务；
2 在养成习惯之前，识别为单独的任务；
3 给小组的会议识别单独的任务；
4 将故障与需求一起排进计划中；
5 尽量按照自然的逻辑顺序安排任务；
6 不确定的任务，先安排一个探针任务；
CH14-8 多人估计胜过单人估计：
1 不确定责任人；
2 纠正责任人的错误估算；
3 通过最大与最小差异识别误解；
4 对错误估计能够承认，反思；
CH14-9 可以做设计，但是不需要很细致。
CH14-10 最好分解到16小时以内。
CH14-11 对用户故事承诺，而不是对用户故事分解后的任务做承诺。这才是聚焦于目标。
CH14-12 是小组一起承诺功能的交付，而不是单个人对自己领用的任务进行承诺。
CH14-13 对于维护历史产品的工作可以根据历史平均值作出估算。
CH14-14 微观估算的不准确性：
CH14-5 一次迭代的开始时间并非一定是周一。
CH14-6 速度驱动的迭代策划：定好本次迭代的速度，即本次迭代可以完成的规模总数，然后添加故事进来，直到填满。
承诺驱动的迭代策划：定好本次迭代的可用工作量，即容量，然后添加故事，拆分任务，估计任务的工作量，累计起来总工作量，直至填满。
CH15-1 任何项目大都至少需要4-5次的反馈。
CH15-2 如果不是自动化测试，则回归测试成本较高，就需要长一点的迭代周期。
CH15-3 选择了一个迭代周期后，就不要改变它，坚持住。
CH15-4 2-4周是比较合适的迭代周期。
CH16-1 三种方式确定开发速度：
历史速度；
尝试一次迭代；
估计；
CH16-2 采用历史速度做估算时，要考虑：
技术是否一样？
领域是否一样？
人员是否一样？
工具是否一样？
环境是否一样？
CH16-3 估算的速度应该是一个范围，而不是一个单点值。
CH16-4 1年的项目，要等开始2个月后再给出一个合理的速度值。
CH16-5 根据实验的速度进行估算速度时，可以成一0.6—1.6得到一个范围。
CH16-6 也可以根据估算锥，每个迭代结束后调整估算速度的浮动范围：
CH16-7 在没有历史速度并也无法实际实验时，可以估计速度：
把用户拆分成任务，然后估计任务的工作量，然后估计每个迭代的可用小时数，用任务去填充迭代，直至填满，然后估计每个迭代的开发速度。
CH16-8 个人工作时可以采用番茄工作法或单核工作法。
CH17-1 buffer的类型：功能缓冲区，进度缓冲区。
DSDM采用了MoSCoW方法划分需求的优先级，并只给70%的计划工作量分配给必需的需求，剩下的30%的工作量作为缓冲。
CH17-2 完成时间的分布：
CH17-3 帕金森定律与学生综合症是一回事
CH17-4 可以采用平方和的平方根方法，也就是2倍标准差的方法估算缓冲区的大小。
CH17-5 更简单的估算缓冲区的方法是用估计值的一半。
CH17-6 项目缓冲区的大小至少是估计值的20%。
CH18-1 多个小组估计时，要建立共同的比较基准与计量单位。
CH18-2 多团队敏捷时，需要更早的明确需求的细节，可以定义出故事的验收标准，但并非必须。
CH18-3 在计划跨团队依赖的任务时，留出缓冲区。
CH18-4 跨团队的缓冲区不要超过半个迭代。
CH18-5 如果跨团队之间的依赖的任务比较大，要考虑进行细拆分。
CH18-6 发布规划时，简单的向前多看几次迭代，滚动前瞻计划。
CH19-1 燃尽图可以有多种画法，可以是折线图，也可以是柱状图。柱状图中底部向下增加的部分是在迭代过程中增加的任务的估计工作量。
这种柱状图的方式实践中很少见。
CH19-2 0-1法度量故事的完成%，没完成就是0。
CH19-3 画柱状图的方法：
只要完成了工作就降低顶部；
对工作重估计时，顶部可能上升也可能下降；
添加新工作时，底部被降低；
去掉工作时，底部被升高。
CH19-4 停车场图也可以用来展示主题的进展。
CH20-1 任务板跟踪每个任务的进展状态。
CH20-2 故障与任务都放在任务板上进行跟踪。
CH20-3 通过燃尽图跟踪离目标有多远。
CH20-4 不要度量个人的速度，小组的速度才是最主要的。
CH21-1 有关估计与计划的沟通是频繁的、诚实的和双向的。
CH21-2 使用大的，可见的图表进行沟通。
CH21-3 使用不包含责任人的功能甘特图跟踪功能完成的进展是可以的。不要使用传统的甘特图。
CH21-4 进度沟通时，过于精确的数字往往容易让人误解为这是一个高度确定的事情或结局。
CH21-5 对迭代速度的三点估算法：最近8次的平均值，最慢3次的平均值，最近1次的平均值。
如：
CH21-5 可以写1个迭代小结对本次迭代进行总结归纳。
CH22-1 敏捷规划有效的8个原因：
经常进行重计划；
对规模与工期的估计是独立的；
在不同层次上做计划；
基于功能而不是基于任务做计划；
小故事保持工作流畅；
每次迭代都要消除处理中的工作；
在小组层次跟踪；
承认不确定性并为之计划；
CH22-2 敏捷估计与规划的12条原则：
让整个小组参与；
在不同层次上进行规划；
使用不同度量单位，让规模和工期的估计保持独立；
用功能或日期来体现不确定性。
经常重计划；
跟踪进度并保持沟通；
承认学习的重要性；
规划具有适当规模的功能；
确定功能优先级；
把估计和计划建立在事实上；
保留一些缓冲；
通过前瞻规划协调多个小组；
CH23-1 用户故事workshop要全员参与。
CH23-2 使用卡片讨论故事，而不是excel，确保大家都看到，都能参与，民主发言。
CH23-3 用户故事的显然目的可以不用写出来。
CH23-4 在用户故事workshop上可以合并比较小的故事，确保聚焦。
CH23-5 为了激发大家把故事考虑的比较全面，可以先考虑用户使用的事件流。
CH23-6 在对用户故事估算时，可以讨论这个故事如何实现。
CH23-7 在上一个迭代（产品）中对下一个迭代（产品）的用户故事进行定义。
CH23-8 在确定开发能力时，要减去例会的时间。
CH23-9 在用户调查需求时，可以合并一些故事，以减少条目，让客户积极参与调查。
CH23-10 产品中要有让用户兴奋的需求。
CH23-11 有些必须的需求可以不用征求客户对优先级的意见。