《敏捷估计与规划》

作者: AgileHouse | 来源:发表于2019-10-02 05:52 被阅读0次

本书结构

第一章：规划的目的

估计和规划问题

很难，有时到项目后期才能得到准确的估计

规划的用途

减少风险：提高对项目的了解，揭示可能会发生的问题

降低不确定性：规划过程中，帮助开发细化产品的“图像”

提供更好的决策支持：在时间、成本、质量之间做出妥协

建立信任：增加开发人员、客户之间认知的一致性，建立信任

传递信息：传递对项目的期待

敏捷规划的特点

更关注规划而不是计划

鼓励修改

产生易于修改的计划

延续到整个项目过程

第二章：规划失败的原因

规划在回答什么

产品要具备哪些能力、在什么时间完成、需要哪些资源、需要多少资源

失败示例

超出预算、无用功能、超出进度

失败的原因

1 基于活动而不是基于功能规划

活动不会提前完成、延误沿着进度表向下传递、活动不是独立的

2 多任务处理导致更多的延迟

分配工作的实际远远早于工作的开始时间，不能很有效的提前分配工作；

提倡项目中所有人达到尽可能高的利用率，而不是保留余量应对典型项目任务中固有的可变性

3 不按优先级开发功能

4 忽视了不确定性

“迭代”可以应对不确定性，使用短的迭代周期，每几周就像用户展示可用的软件

5 把估计当承诺

第三章：敏捷方法

敏捷宣言作者的价值观

个人与交互重于开发过程与工具

可用的软件重于复杂的文档

寻求客户的合作重于合同的谈判

对变化的响应终于始终遵循固定的计划

敏捷的开发方法（敏捷小组）

作为一个整体工作：每个角色都是产品所有者，共同愿景，不相互丢球；敏捷中项目经理更多关注领导而不是管理

按短迭代周期工作：迭代要受时间框（timebox)限制的，即便放弃一些功能，也必须按时结束迭代。时间框一般很多，2-4周，也有长的，可在每次迭代开始的时候选择合适的周期长度。

每次迭代交付一些成果：每次迭代都有一些可交付的成果，经过了编码、测试；由于单次迭代不总能提供足够的时间来满足用户或者客户的需求（如MTBF测试），因此引入了发布release的概念，最常见的是2~4周一个迭代，2~6个月一次发布。

关注业务优先级：功能优先级灵活、之间依赖小。轻量级技术"用户故事“

检查与调整

敏捷规划方法

知识储备：产品知识，认识产品是什么；项目知识，开发小组使用的技术、风险等知识

规划不同的层次（规划洋葱）：用户故事、迭代、产品、资产、战略

满意条件：衡量成功的标准，进度、预算、质量

第四章：使用故事点估计规模

4.1 故事点是相对的

是对用户规模的相对度量。具有10个故事点的规模、复杂度或者风险应该是具有5个故事点的用户故事的两倍。有意的只是分配给不同用户故事的点值得相对大小。

4.2 速度

对开发小组的进度率的估量，可以通过计算小组在一次迭代中完成的用户故事数上分配的故事点数来得到速度。如果小组完成3个每个估计值为5点的用户故事，他们的速度就是15。

在每次迭代结束的时候，开始发小组可以看看他们完成了那些用户故事，通过计算完成的用户故事的故事点估计之和来得到小组的速度。

工作量的估计和持续时间的估计是独立开来的。工作量是相对的，持续时间取决于速度，可以相对调整。一个项目的持续时间是通过取项目的故事点数，在除以小组的速度而推算出来的。

第五章：使用理想日进行估计

理想时间（ideal time）是某件事情提出了所有外围活动之后所需要的时间。

耗用时间（elapsed time）是时钟上显示流逝掉的时间。

使用理想日而不是耗用日，更容易估计开发一个用户故事所需的时间量。这时，理想日是对规模的估计，虽然她的以以没有故事点那么严格。

使用理想日进行估计时：需要假定所估计得用户故事时您将处理的唯一工作、您所需要的所有东西在您开始工作的时候都会准备好、不会被打断。

采用理想日进行估计时：最好职位每个用户故事分配单一的估计值，应该把所有需要的时间加一起（如开发、测试、产品等），而不是单独说某一部分的时间，把他们当作一个整体更符合敏捷的规则，也减少追踪的开销。但有时候，单独追踪也是有必要的，视情况而定。

第六章：估计方法

在进行估计活动时，要记住对投入时间的汇报渐减这一法则（即回报的增长幅度随着投入的增加而减少）。

共同估计

首先，在敏捷开发项目中，我们往往不知道一项工作由特定的哪个人来完成。由于任何工作都可能被任何人完成，因此让每个人都参与估计时非常重要的。

其次，虽然我们可能期望数据库专家来完成这项工作，其他人对他的估计值也可能有以间需要表达。

估计的尺度

估计应该基于一个预先定义的尺度。将在最近处理的功能以及需要非常可靠估计功能应该足够小，从而可以使用1~10之间的非线性尺度，例如1、2、3、4、5、8或者1、2、4、8来进行估计。不太可能在最近的借此迭代中实现大功能可以不分解，用大的单位如13、20、40、100来估计。有些小组选择在估计尺度中包含0。不到1个，但是也具有工作量。

用户故事、史诗、主题

大型的用户故事有时候被称为史诗（epic）。

一组相关的用户故事可能会被结合在一起，并在估计时和发布规划中都被当作一个单一的尸体。这样的一组用户故事被称为一个主题（theme）。一个仅根据规模所成的史诗，往往本身就是一个主题。

得到估计值得方法

专家意见、类比、裂解

专家意见：好处节省时间，但是这种方法在敏捷开发项目中没有在传统项目中那么有效。在敏捷开发项目中，是对用户故事或者其他用户认为有价值得功能进行估计。开发这种功能可能需要多个人才能具有得数种技能。

类比估计：以这种方式估计时，不用把所有的用户都对一个基线或者通用参照进行比较，而是把每个新用户故事和那些意见估计过的故事进行比较。被称为“三角测量”。如，判定一个用户故事是否应该被估计为5点，就看一下他是否比一个您估计为3点的故事大一些，同时又比一个您估计为8点的故事小一些。

裂解（disaggregation）是指将一个用户故事或者功能分解为更小、更容易估计的部分。不过，需要当心不要再这种方法上做过了头。当过分进行裂解的时候，不仅忘记某项任务的可能性会增加，而且对大量小任务的估计值求和也会出现问题。

规划扑克

规划扑克把专家意见、类比和裂解结合到一种令人愉快的规划方法中，可以产生快速但是可靠的估计。

规划扑克的参与者包括小组的所有成员（如程序员、测试人员、数据库工程师、分析员、用户交互设计师等）。敏捷开发小组一般不会超过10人，如果超过最好分成两个小组。每个小组可以分别估计，从而保证每个小组都不会太大。产品所有者参加规划扑克，但是不参加估计。

组织者负责说明故事点，大家分别在扑克下写下估计值，同时亮出，如差异较多，请估计者阐述原因，然后再次进行估计。估计的中点在于合理性而不在于绝对的精确。一般不超过三轮就可以定出。注意把控时间（比如可以准备个沙漏，到两分时间翻一次，帮助小组学会更快的估计）如果在有限的时间内未给出一致性的结果，可以先进行下一个估计。

更小的会议：让小组的一部分人而不是所有人来打规划扑克。这不是一种理想的做法，但有时时一种合理的选择。尤其是很多对象需要估计得时候，这时可以把大得小组分成两个或者三个更小组，每个组至少三名估计者。队伍之间做出一致的估计很重要。

如何打规划扑克：开发小组需要在两个不同时期打规划扑克。首先，在项目正式启动前或者在它的第一次迭代中，通常会有大量的对象需要进行估计。其次，小组需要在开发过程中对迭代中发现的新用户故事进行估计。一个方法是预先规划在每次迭代快结束的时候进行一次短小的估计会议，通常，这样做足以对迭代中出现的工作进行规划，并且允许在接下来这次迭代确定优先级时对新工作加以考虑。另外一种替代方法，建议墙上挂个锌粉个，把所有新用户故事都放到信封中，当某个人有空的时候，就从信封中拿出一两个故事进行估计。或小组应该自己建立一条规则，在这一天或者这次迭代结束之前完成对所有新故事的估计。

为什么规划扑克会有效？

首先规划扑克在做估计时把多条专家意见放到了一起。其次在规划扑克期间进行活跃的对话，规划者会同事要求证明自己的估计得正确性。对个人估计的平均可以引向更好的结果，对估计进行团体讨论也可以得到同样的效果。团队讨论时规划扑克的基础，这些讨论会导向对个人估计得平均。最后，规划扑克起做用的原因时它很有趣。

第七章：重估

不进行重估的情况

速度是很好的均衡器：故事点保持一致性

需要重估的情况

不进行重估、重估完成的故事、相对规模改变时进行重估

第九章：确定主题的优先级

确定优先级时的因素

1 获得这些功能带来的经济价值

2 开发（可能还包含支持）新功能所需要的成本

3 开发新功能所产生的学习和知识的量及重要性

4 开发这些功能所减少的风险

（敏捷开发的初期不确定性高->慢慢降低的过程，传统瀑布式的不确定性较高），敏捷开发一般先开发初一部分并展示给客户，收集反馈和提炼看法，并对计划做一定的调整。

进度风险、成本风险、功能风险，技术风险、商业风险

第十章：确定经济优先级

预测主题的经济价值时产品所有者的责任，但这个责任和小组其他成员是共同承担的。

如果可以估计每个主题所阐述或者节省的金钱数目，就可以使用它来帮助确定优先级。

主要经济目标：净现值、内部收益率、回收期、贴现回收期

收入的来源

新收入（new revenue）

增量收入（incremental revenue）：把来自新客户的收入和来自现有客户的额外的、增加的收入区分开，往往是有益的。增量收入的产品是新的系统或者产品可以：促进现有客户个欧美更多的许可，包含了可以独立出售的可选、附件模块，包含玉虚提高收费的功能，促进对咨询服务的使用。

留存收入（retained revenue）：如果不开发项目或者主题，公司会损失的收入。与新收入和增量收入相独立，但这里也有增量收入的机会。

操作效率（operational efficiency）：要考虑任何需要或者在公司成长后需要很长时间的事，部门之间更好的集成和交流，降低的人员更替，对新员工更短的培训时间，任何对时间敏感的过程，综合多个过程，任何可以提高准确性和减少返工的机会。

经济指标

金钱的时间价值

现值（present value）：为了在将来达到特定的数值而需要在今天投资的进而被称为现值。

贴现（discount）：把将来的金额推回它的价值的过程被称为贴现。用户对将来的金额进行贴现的利率对确定将来金额的价值事非常关键的。机会成本（opportunity cost）只得就是对将来的金钱进行贴现的利率，反应了为进行这个投资而放弃其他机会所可能损失的收入百分率。

净现值（NPV ：Net Present Value)：确认净现值，需要将一系列的将来的金额的现值累加起来。

i是利率，而Ft是周期t中的净现值现金流。

内部收益率（internal rate of return，irr），也称投资收益率（return on investment，roi），提供了一个百分比形式表示项目利润的方法。净现值是对一个项目的预期利率由多少的度量（按照当前的现价），而内部收益率度量是在项目上投资的价值增长有多快。

最低投资回报率（minimum attractive rate of return，MAAR），只有内部收益率超过了最低投资回报率的项目或者主题才会得到资金支持。对净现值则无法设置一个类似的阈值，因为净现值对项目的大小存在很高的依赖性。如果设置了一个净现值的阈值，小的（但有价值的）项目永远不会被接受。

回收期（payback period）：利用净现值，我们可以把一个现金流看作一个单一的现价数值。另外我们也可以把现金流看到利率，看到现金流的另外一种方法是考虑赚回初始投资需要多少时间。使用回收期比较主题和优先级的好处：计算和解释很直观，度量了开发公司所承担的经济风险的量和持续时间。回收期越场，项目的风险越高，因为这段期间很多时期都可能发射变化。主要缺点是，没有考虑金钱的时间价值，不是对项目或者主题的盈利性的度量。

贴现回收期：可对回收期计算的第一个缺点进行修正，我们只需要简单的对先现金流中的每一项应用正确的贴现参数。注意贴现回收期不等于回收期。

第十一章：确定合意性优先级

客户满意度的Kano模型

作为阈值的功能，或者说必须的功能

线性功能，越多越好的功能

兴奋点和惊喜点，有会惊喜没有也不影响满意度，一般指未被了解的需求

客户满意度Kano模型

Kano调研

分别从有这个功能和没有这个功能两个维度考量

我希望就是这样、我预期就是这样、我没有意见、我可以忍受这样、我不希望这样

相对权重调研

提供一种使用一个值来对实现一个功能所带来的收益、不实现它所带来的惩罚和实现它的成本进行估计得方法，这个值就代表了功能得优先级。

第十二章：分割用户故事

何时需要分割用户故事

当用户故事太大，不能放进单次迭代的时候，另外，一个用户故事可能足够小，可以放进单次迭代，但是由于正在规划的迭代中剩下的时间不够，因此它也不适合这次迭代。其次，对大型用户故事进行分割有助于做出更准确的估计。

按照数据边界分割

按照它将要支持的数据进行分割，按照用户故事所支持的边界来分割大型用户故事。

按照操作边界分割

按照大型故事中进行的操作对其进行分割，完成这一过程常见方法是根据通常的CRUD操作，建立create、读取read、更新update、删除delete。

去除横切顾虑

横切（cross-cutting），在典型的应用软件中有很多正交的或者说横切的功能，也就是在很多独立的功能中都要用到的相同功能。可以通过把它和一个或多个这样的横切考虑隔离开而缩小。例如口令长度和字符限制条件等公共约束，在做功能时可以先不考虑。

考虑去除横切考虑（例如安全处理、日志记录、错误处理等），为用户故事建立两个版本：一个具备对横切考虑的支持，另一个不具备这种支持。

不用满足性能限制

考虑把功能性和非功能性需求隔离到不同的用户故事，从而分割小型用户故事。

分割具有混合优先级的故事

如果大型用户故事中的小故事具有不同的优先级，则可以对它们进行分割。

不要把故事分割成任务

不要把大型故事分割成任务，而是寻找一个方法来让一颗曳光弹穿过整个故事。

如不要把用户故事分解成：对用户界面编码、编写中间层。要穿越一项功能的所有层。交付一项功能所有层的一个内聚子集，几乎比只交付一个层要好。

避免相关变化的诱惑

避免在具有适当规模的功能中增加相关变化而把事情弄糟，除非这些变化具有同样的优先级。

一旦您分割了一个用户故事，得到了适当的规模，就不要再向故事中增加工作而把事情弄糟。”当我处理这些代码的时候，我可能也要处理其他已经存在的变化“。有时会遇到在处理一个独立的问题时，修改同一部分代码中存在的错误或者结节其中一个老问题，很可能是合适的做法。但是需要按照和考虑其他功能优先级。

组合用户故事

用户故事并不是分割的越小越好。对按照2周一次的迭代周期工作的开发小组来说，合适的做法时分割功能时它们大约2~5填内完成。（可能仍然以故事点来对用户故事进行估计，但是到小组需要分割用户故事的时候，我们应该已经大致知道多个故事点或者理想日相当于2~5天）。对于一周的迭代周期用户故事要更小一些，对更长一些的迭代周期，用户故事则可以大一些，但也不一定非要大一些。接近这些适当规模的用户故事最适合敏捷开发项目的短迭代周期。

正如要分割大型故事，我们也可能需要组合多个小故事。组合的故事将作为整体进行估计而不是分别进行。可能的话，尝试组合相关的故事，因为这样可以简化确定他们优先级的工作。很常见的做错事组合多个错误报告并把他们当作一个事项进行处理。

第十三章：发布规划基础

发布规划就是建立很高层次的、覆盖超过一次迭代周期长度的机会的过程。一次典型的发布可能会覆盖3~6个月，而且根据迭代周期的长度，可能具有3~12次或者更多的迭代。

发布计划很重要的原因

首先，可以帮助产品所有者和整个开发小组判定他们在获得一个可发布产品之间，必须花多长时间开发所有东西。产品越早发布，开发公司就可以越早开始获得在项目中的投资回报。

其次，发布计划船体了对于在多长时间内可能开发什么内容的期望。很多公司需要整个信息，因为它可以用于其他的战略规划活动。

第三，发布计划可以作为项目小组前进的路标。如果没有发布的概念，小组就无止境的从一次迭代走向另一次迭代。发布计划提供了把迭代组合成一个令人满意的整体的相关背景。这对于任何迭代式过程，而不仅仅是敏捷开发，都是一个基本的考虑。通过建立发布计划，让小组开发成员看到他们目前希望最终到达那里。

发布计划

确定满意条件：在开始规划一次发布前，了解根据哪些准则来判定整个项目的成败。大多使用进度、范围、资源。一般说项目要么是由日期驱动（date-driven），要么功能驱动（feature-driven）。

估计用户故事的规模：估计值代表了开发用户故事的成本，对每个故事都进行估计就非常重要。对产品所有者所需要的每件事都进行估计事不必要的，只需要对哪些有合理性的可能性会被选中包含到即将来临的发布中的新功能分别进行估计。产品所有者的希望列表常常会延伸到未来的两次、三次甚至更多次的发布。并不需要为遥远的工作进行估计。

选择迭代周期长度：大多数采用2~4周迭代周期。时间更长或者更短也可，规划一次发布的适合，需要选择合适的周期长度。详情可参考第十五章。

估计速度：最好的办法一般是使用他们最近表现出的速度。但如果采用技术或者针对的业务领域发生了显著的变化，使用小组过去的速度可能就不合适了。不过仍然可以采用一些方法来根据过去的结果得到一个有道理的速度估计。详情可参考第十六章。

确定故事优先级：好的产品所有者会承担确认优先级的最终责任，但是会考虑开发小组其他成员的建议，尤其时有关开发顺序的建议。根据前面所提出的指导原则，可以确定用户故事的优先级。

选择用户故事和发布日期：这个时候，已经获得了小组每次迭代的开发速度估计，并有了一个将会有多少次迭代的设想。现在可以看一下是否可以规划出可以满足项目满意条件的发布计划。如果是功能驱动，可以对所有必须功能的规模估计值求和，除以预期的速度，就可以得到完成这些功能所需的迭代次数。如果是日期驱动，可以查看日历表确定迭代的次数，将迭代的次数乘以预期的速度可以告诉我们发布中可以有多少个故事点或是理想日。可以在用户故事的优先级列表中数出这么多的故事点或理想日，了解在要求的时间内可以完成的功能。

接下来要解决发布计划应该有多详细的问题。有些小组倾向于建立一个显示出他们在每次迭代中要开发什么的发布计划，其他小组倾向于简单的觉得他们认为在整个发布中要发开什么，而把每次迭代的具体内容留到以后考虑。两种方法各有优缺点，要对把工作分配到特定迭代所付出的时间和精力做出权衡。

典型的发布规划会议中会有大量的讨价还价（give-and-take）和假设分析问题，我们需要一个简单操作的方法来记录哪些有放到这次发布和它的迭代，哪些没有。记录卡牌和便利贴是一个好选择，是有形的，容易共享。

更新发布计划

应该按照一定的频度对发布计划进行重访和更新。如果开发小组的速度保持的相当稳定，而且迭代规划没有产生出乎意料的事情，可能会长达4~6周都不用正式的更新发布计划。另一方面，很多项目都从每次迭代后重放发布计划的规则中受益。

总结补充

发布计划并不需要精确说明在每次迭代中要完成哪些工作。实际上，很少会需要这一水平的细节。对大多数项目而言，指出第一次迭代中要处理的用户故事就足够了，可以把剩下的用户故事留到以后再按优先级分配到其他的迭代中。

发布规划是一个迭代的过程，首先要确定产品所有者对整个项目的满意度。如果无法规划一个项目来满足最初的满意条件集，就需要重复规划过程，看是否能够满足一个缩小了的满意条件集；不然的话，也许可以晚一些交付某些要求的功能，或者采用一个更大的开发小组。

第十四章：迭代规划

发布计划是一个很好的高层次试图，显示了开发小组如何试图交付他们能够完成的最具有价值的产品。但是发布规划只提供了药构建的产品的高层试图。它没有提供可供小组用于驱动迭代中会发生的工作的短期、更为详细的视图。

在迭代计划中，开发小组将会更为专注、更为详细的研究，要完全实现哪些为新的一次迭代所选择的用户故事，哪些事情是必须的。

迭代计划在迭代规划会议上制定的。相关人员都应参加这个会议。形式上，可以是简单的电子表格，或者一组在每张上都写有一项任务的记录卡片。无论什么形式，都应将任务和用户故事组织起来，以便可以了解某项任务是和哪个故事有关。

迭代规划时不分配任务

个人一开始不会签订任务，在迭代开始之后才逐步地每次签订一两项相关的任务。在完成已经选择的任务之前不会开始新的任务。在迭代规划的时候把人员分配到特定的任务不会带来什么收获，但却会有很多损失。在小组成员抱有“我们是一个整体”的态度时，项目才会完成的最好。小组成员会相互弥补其他人为完成的工作，并且知道别人对自己也会这么做。如果个人在迭代开始时就签订任务，这种做法与为达到迭代目标而做出统一的承诺是矛盾的。

迭代和发布的区别

发布计划是对整个产品发布过程的展望，与之相对，迭代计划知识对一次迭代的展望。

敏捷规划成为了一个有两个阶段的过程。第一个阶段产生发布计划，边界粗糙并具有总体得不确定性。第二个阶段产生迭代计划，迭代计划仍然有一些粗糙得边界，也存在一些不确定性。但是，由于在开始一次新的迭代得同时建立它得迭代计划，所有迭代计划会比发布计划详细得多。

迭代规划的方法

1 速度驱动

调整优先级：

迭代回顾会议，一般安排在迭代结束前两天。迭代回顾会议和迭代规划会议可以放在同一天进行。尽量不要把迭代结束时间放到月末或者季末，一般这两个时间事情比较多，请假的几率也较大，风险大。

把用户故事分解成任务：

把用户故事变成可用的、完成的产品所需要进行的所有任务都应该被鉴别出来。如分析、设计、用户交互设计、测试、编写文档等任务。包含测试任务的重要性在于，小组在迭代开始的时候就需要考虑应该如何测试用户故事。这样测试人员从迭代一开始就参与进行，从而改善小组的跨功能行为。

原则：

1 只包含为此项目增加价值的工作（不能包含如回复邮件1小时之类的任务）

2 尽量明确直到养成习惯（如新的敏捷开发小组不熟悉或者不能熟练的编写自动化单元测试，要逐步养成习惯，在养成习惯之前，明确这项任务可以帮助大家更注意它）

3 考虑到会议（很重要）

4 故障，我们偏向确定一项任务，但在它通过所有测试之前不认为已经完成。实际，故障应该与用户故事一样的方法来对待。应该按照与用户故事一样的方法确定缺陷修复工作的优先级，分配到后续的某次迭代中。

5 处理依赖性，自然顺序通常就是开发小组对故事进行估计的时候所设想的顺序，如果处理用户故事的顺序和进行估计时的设想不一样，小组在进行迭代规划的时候往往就需要包含附加任务来使得他们可以按照新顺序处理这些用户故事。

6 难以分割的工作，某些功能难以分解成任务。

如有意向不确定的工作，我们写下了两个任务：确定受影响的部分--2小时；进行改动--10小时。

第一项任务成为探针（spike）：包含在迭代计划中，专门用来获取知识或者回答问题的任务。

在这个例子中，小组难以推测某件事，所有建立了两项任务：一个探针和一个占位符，占位符中是对持续时间的猜测。这个探针可以帮助小组了解他们应该如何处理另一项任务，从而允许他们对它进行估计。

对任务进行估计

速度驱动的迭代规划的下一个步骤是每项任务进行估计。一些小组选择在确定了所有任务之后对他们进行估计，其他小组则每确定一项任务就估计一项。对任务的估计是以理想时间表述的。

可以进行一些设计（建立任务和估计值列表的时候进行一些时间是必须的，如果完全不知道将如何开展工作，就无法建立任务列表，在规划一次迭代的时候，不需要在功能设计上走到更远）。任务的合适规模（建立的任务应该具有使适当的规模，这样每个开发人员大致上能够每天完成一项。这样的规模可以有效的让工作顺畅的流过敏捷开发过程。更大规模的任务可能会在一两个开发人员手上产生瓶颈，小组的其他人就智能等着他们完成任务）

2 承诺驱动

任务估计值和故事点的联系

实际花费时间不一定完全和估计值相同

迭代的起始时间也不一定是周一开始周五结束，试需要而定，如周五开始，周四结束，如有问题可以周末解决，周四结束后，还有时间做下一次的规划。

第十五章：选择迭代长度

影响因素

正在处理的发布的时间长度

不确定的多少

获得反馈的难易程度

优先级可保持多久不变

不用外部反馈自行工作的意愿的强弱

迭代的系统开销

紧迫感的产生有多快

发布时间总长度

短时间的项目从短迭代中收益，项目迭代的长度决定了：

能够多频繁的向客户和用户展示软件（以潜在可以交付的形式），确实可以在软件迭代中期的形式展现给观众，但是迭代结束后才具有潜在可以交付的质量。

能够多频繁的度量开发进度。在一次迭代进行中，也可能获得对小组进度率的感觉，但是只有在迭代结束的时候我们才能真正的度量到底完成了多少工作。

产品所有者和开发小组能够频繁的修正自己的路线。因为只有在迭代之间才会对优先级和计划进行调整。

坚持达到稳定的节奏

一般倾向于2周的节奏、高度探索性的阶段可4周的节奏(四周会给人清晰的开始、过程、结尾的感觉)；但一直2周的节奏可能会给人过度的紧张，可以6*2+1，一周过渡期自行确认工作的优先级，清理技术欠账

第十六章：估计速度

使用历史值

历史值的问题在于，只有过去的项目和小组与现在的项目和小组没什么差别的时候，它们才具有最大的价值。任何人员的变动或重要技术的改变都会减少速度的历史度量值的用处。在使用它们前应该问自己几个类似下面的问题：

使用的技术是否一样？所针对的领域是否一样？开发小组是否一样？产品所有者是否一样？使用的工具是否一样？工作环境是否一样？对项目的估计是否由相同的人进行？

当上述有否的答案时，可以根据下图建立一个范围，就是大致的正确比准确的错误要好。

进行一次迭代

预测速度的理想方法时进行一次迭代（或者2~3次），然后用这1~3次迭代的观测速度（observed velocity）来估计速度。大多数项目经理可以把给出估计值的时间推迟至少一次迭代。然后利用不确定性锥形在那个数据点周围建立一个范围。所以如果您进行了一次迭代，得到的速度时15，可以把它诚意0.6~1.6得到从9~24的范围。如果可以在给出速度估计值之前让小组进行3次以上的迭代，如分别是12、15、16，那可以用更简单的方法确定，即是12~16之间。也可以再次使用预测锥形进行预测。

做出预测

有时候，没有历史数据，也不能进行几次迭代来观测速度，可以假设是为一个12个月以后才会启动的项目做出估计。或者假设项目也许很快就会启动，但是只有在客户为该工作签署了合同之后才会开始。这种情况有两个关键点：希望目前在项目上花费最小化，项目可能不会发生，或者在遥远的未来才开始迭代，其次对项目的任何估计都必须反应很高度的不确定性。

这种情况，需要对速度做出预测。对速度做出预测很少会成为首选方法，但是是一个重要的可选方法。预测速度的最佳方法涉及把用户故事扩展成组成他们的任务、估计这些任务（如同我们规划一次迭代时所做的一样)、了解每次迭代中适合放多少工作，并计算如果在一次迭代中完成了那些工作，速度是多少。

包括下列步骤：

1 估计每个人每天可以用在项目上工作的小时数

2 确定在迭代中可以用在项目上的总小时数

3 任意地、在某种程度上随机地选择用户故事，把他们扩展成组成它们任务，重复这个步骤知道确定了足够的任务来填满迭代中的小时数。（扩展故事并寻找适当的技能集）

4 把上述步骤确定出的速度转换成一个范围。（在点值周围设置一个范围，如乘上60%和160%）

选择合适的方法

指导原则：

1如果在给出对速度的估计前可以进行一次或更多的迭代，总是这样做。看到小组的实际速度是最好的选择

2使用该小组在一个相关项目上的实际速度

3通过看那些工作适合来估计速度

无论哪种方法，都要尽早切换到使用实际的对速度的观测值。

第十七章：为不确定性缓存计划

功能缓冲区

最小发布集合+多选择20%~40%的其他工作

DSDM（dynamic systems development method）：动态系统开发方法

MosCow有规则：必须有的must、应有的should have、可有的could have、不会有的won't have

进度缓冲区

在估计值中反应不确定性

调整缓冲区大小

例如

更简单的缓冲区计算方法

前述确定缓冲区大小的方法是最好的方法，但是如果由于某些原因无法同时得到50%和90%的估计值，还有一个更简单的方法。在50%的水平上估计每个故事，然后把缓冲区的大小设置为这些50%估计值之和的一半。要保证小组都指导给出的估计值应该具有50%的确定性的估计，希望估计得偏高和偏低得可能性一样。

这种方法有个很严重的缺点，就是不会收到项目中特定故事周围实际不确定性的影响。比如两个故事，50%估计都是5点，但是90%估计一个是10，一个是100，这个就无法考虑。如果有机会得到两个估计值，还是倾向于基于平方和的平方根的方法。

缓冲区准测

1 平方和的平方根在有10个以上的用户故事或者功能被估计时最可靠。但是如果项目中的故事或功能少于10项，不建议规划缓冲区。

2 项目缓冲区至少应该反应整个项目持续时间的20%，更小的缓冲区也许不能为整个项目提供足够的保护。

结合多个缓冲区

进度缓冲区：是在除去了局部保险的估计值和上增加的必要的安全边界，不是填料padding，在估计值周围随意增加的额外时间

建议：增加缓冲区注意乐观和悲观概率的平衡和选择；若项目没有精准的最后期限和明确的交付功能级集，只是简单的希望在支持的时间内尽快交付高质量的软件，不应在额外添加缓冲区；注意域其他人进行有关缓冲区的沟通，不该掩盖它们的存在，但是有可能被别人认为padding，所以要注意和他人交流任何得到这个值，并提供每个人都信任的进度表。