delphi 双缓冲_敏捷软件开发实践：估算与计划读书笔记119第17章 不确定性缓冲计划...

《敏捷软件开发实践：估算与计划》第17章 不确定性缓冲计划，重点和要点的思维导图及文字内容。

第17章 不确定性缓冲计划

To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.

很多人抱怨敏捷计划不能有效地应用于下列典型环境：

1. 提前很早就制定项目的计划。

2. 项目必须满足一个严格的最终期限，并包含一个相当严格的功能集。

3. 项目是由一个公司承包给另一个公司的。

4. 对需求的理解处于非常肤浅的层次上。

5. 公司对让进度表具有太多的灵活性感到很不舒服，即使对那些不需要严格的最终期限和可交付物的项目也是如此。

处于这样的环境之中的项目的共同之处在于，它们要么具有很高的额外的不确定性，要么一旦出错就会产生非常严重的后果。

另一种情况是项目管理者被要求在一个严格的最终期限内承诺交付一组核心功能。

在确定进度表时包含缓冲区是非常有用的。缓冲区就是在估算值周围的误差许可范围。在有很显著的不确定性或出错代价很高时，包含缓冲区是明智的做法。缓冲区有助于保护项目免受不确定性的冲击。对项目进度表进行缓冲是一项合适的风险管理策略。

17.1 特性缓冲区

通过特性来缓冲项目的做法就是告诉客户，我们会提供这堆功能的全部，可能还会提供那堆功能中的一部分。

在敏捷开发项目中建立一个功能缓冲区的步骤如下：

一，客户选出所有那些绝对必需的工作。对这些工作的估算值被加到一起，这就代表了可以发布的最小特性集合。

二，客户再多选择 25%~40%的其他工作，作为具有更高不确定性或者对进度风险承受力更低的项目的工作量范围上限。对这些工作的估算值被加到初始的估算值上，就得到了对项目的总体估算。

三，和平常一样把交付整个功能集作为项目的计划。不过，其中的有些工作量是可选的，时间许可时才会包含进去。只有完成了那些必需的工作之后，才会最后开发这些可选的工作。

在 DSDM 项目中，需求分为 4 类：必需有的(Must Have)，应该有的(Should Have)，可以有的(Could Have)和不会有的(Won't Have)。DSDM 把这个分类方法称为 MoSCoW 规则(莫斯科规则)。

17.2 进度缓冲区

17.2.1 在估算值中反映不确定性

我们需要一种量化不确定性的方法来保护项目进度表免受不确定性的影响。团队估算用户故事的理想人天的数值，就是假定这个数值反映了团队对开发某个功能所需时间量的估算。不过，更合理的方式是确定该工作可能会在某段时间范围内完成。

帕金森定律是说：工作总是要拖到最后一刻才完成。学生综合症是指在快要不能成功完成的最后时刻才开始做一件事——比如，在考前一周才开始复习。一个较短但是包含了进度缓冲区的进度表可以预防帕金森定律和学生综合症所导致的问题，它比一个更长时间的进度表更可能被实现。

要为软件项目建立进度缓冲区，我们需要做的第一件事就是修改我们的估算过程，让它可以为每个用户故事或特性生成两个估算值。即我们需要知道对每个故事或功能的 50% 和 90% 估算值。这相当容易：当团队聚在一起进行估算时，先估算第一个用户故事的 50% 值，然后估算它的 90% 值。之后再移动到下一个故事或者功能。

17.2.2 调整项目缓冲区大小

增加进度缓冲区可能会(也可能不会)在项目的长度上增加一次或多次迭代。通常情况下，它会增加一些迭代。

17.2.3 更简单的缓冲区计算方法

如果由于某些原因无法同时得到 50% 和 90% 估算值来确定项目缓冲区大小，可以采用更简单的方法：在 50% 的水平上估算每个故事，然后把缓冲区的大小设置为这些 50% 估算值之和的一半。这个简单的方法有一个很严重的缺点：不会受到项目中围绕着特定用户故事的实际不确定性的影响。建议使用基于平方和的平方根的方法，这是确定项目缓冲区大小的最好方法。

17.2.4 缓冲区准则

请考虑以下两个准则：

1. 平方和的平方根方法在有 10 个以上的用户故事或者功能被估算时最可靠。但如果你项目中的故事或功能少于 10 项，也许根本就不应该计划缓冲区。

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

17.3 结合多个缓冲区

我们要保护项目不受多种类型的不确定性影响时应该使用多个缓冲区。

我们应该使用适当的元素来缓冲特定类型的项目不确定性，即用特性来缓冲特性不确定性，用时间来缓冲进度不确定性。

在使用多个缓冲区时，每个缓冲区的规模都可以更小。

我们只有把项目的特性和进度缓冲区结合起来时，项目才能真正得到保护，免受不确定性的影响。

17.4 进度缓冲区不是填料

填料(padding)是指在估算值周围随意增加的额外时间，带有轻蔑的意思。

一个人如果预期自己在给出错误估算时会受到惩罚，就会给估算值添加填料。

进度缓冲区与填料不同：进度缓冲区是在除去了局部保险的估算值的总和之上增加的必要安全边界。

给项目留出适当的缓冲区对项目的安全是很关键的。

当允许在交付日期和功能上都具有少量灵活性时，就可以在两个维度上为项目提供缓冲。

用适当的资源来缓冲项目的每个限制条件：用时间来缓冲最后期限；用特性来缓冲特性。

当我们不能适当地缓冲一个限制条件时，就必须加大其他缓冲区的规模。

如果团队不得不保证功能的实现，团队就应用一个更大的进度缓冲区来支持这个保证。

17.5 一些警告

注意下列有关给项目增加一个或多个缓冲区的警告：

1. 增加进度缓冲区时，应该使用双估算值的方法，或明确单个估算值代表的是 50% 可信的估算。

2. 大多数项目并不存在一个精确的最后期限和一组精确的交付功能集，团队只是简单地需要在受支持的时间内尽快交付高质量的软件。

3. 在与其他人进行有关缓冲区的沟通时，不应该掩盖它们的存在，也不应该掩盖它们的使用方法。

17.6 小结

大多数项目都包含大量的不确定性。项目团队往往没有在进度表和最后期限中反映这种不确定性。

当不确定性非常大或非常显著时，就需要在估算项目持续时间时采取一些额外的步骤，这些情况可能包括：提前很早就进行项目计划，项目必须绝对满足最后期限(同时交付一组相当严格的功能集)，项目是外包的，需求仍然处于非常表面的层次，或者在日期出错时会产生严重的影响(经济或其他方面)等。

特性缓冲区和进度缓冲区是两类最常见的缓冲区。

当团队发现可能无法交付所有功能时，就需要建立一个特性缓冲区。

当时间不够用时，通过放弃特性缓冲区中的事项来达到进度表的时间要求。

团队可以在进度表中包含一定量的时间来建立进度缓冲区以反映项目规模中的不确定性。

团队可以通过同时估算每个用户故事的具有 50% 概率的大小和具有 90% 概率的大小来构造进度缓冲区。

通过对每对 50% 和 90% 估算值采用平方和的平方根公式，可以估算出合适的进度缓冲区大小。

项目应该用特性缓冲区来预防特性不确定性，用进度缓冲区来预防进度不确定性。可以把特性缓冲区和进度缓冲区结合起来。这可以让每个缓冲区的规模都更小。

---

版权声明

本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。 如果你觉得本文有用，欢迎分享给其他人。谢谢。

---