sap business one 开发_敏捷软件开发实践：估算与计划读书笔记116第14章 迭代计划...

《敏捷软件开发实践：估算与计划》第14章 迭代计划，重点和要点的思维导图及文字内容。

第14章 迭代计划

It is a capital mistake to theorize before one has data.

发布计划是一个很好的高层次视图，显示了团队预计如何交付他们所能够完成的、最具价值的产品。发布计划只提供了构建的产品的高层视图，而没有提供短期的、更详细的、可供团队用于驱动迭代工作内容的视图。

在迭代计划中，团队将更专注、更详细地研究哪些事情对于要完全实现那些新的迭代所选择的用户故事是必需的。迭代计划是在迭代计划会议上制定的。产品负责人和开发团队都应该参加这个会议。所有参与到把原始想法转变成可工作的产品这一过程的人都应该参加这个会议。

从形式上讲，迭代计划可以简单就是一个电子表格，或就是一组每张上都写有一项任务的记录卡片。无论采用哪种形式，都应将任务和用户故事组织起来，以方便了解某项任务是和哪个故事相关。除了电子表格，还可以用记录卡片来做迭代计划：可以在桌子或地板上编排卡片，也可以把卡片粘到或者钉到墙上。对于集中办公的团队，建议使用记录卡片做迭代计划。对于使用软件来管理项目开发的团队，可以在会议中使用卡片，然后在会后将卡片上的内容输入软件系统即可。在迭代计划中使用记录卡片的最明显的优点是：它允许每个人都参与到这一过程中。

14.1 迭代计划时不分配任务

在迭代计划会议上，任务不会分配给特定的个人。个人直到迭代开始之后，才会去签署(Sign up，原意指把自己的名字签写到故事卡上面，领取之意)任务，并且一次一般只签署一两项相关的任务。在完成已经选择的任务之前，个人不会开始新的任务。

14.2 迭代计划和发布计划的区别

发布计划是对整个产品发布过程的展望，通常是从新项目启动开始 3~9 个月的时间。对发布计划中的用户故事进行估算时采用的是故事点或理想人天。

迭代计划是对一次迭代的展望，通常是 1~4 周的时间。在迭代计划中，发布计划中的用户故事分解成任务。对迭代计划中的任务进行估算采用理想小时。

迭代规划会的主要目标是对在粒度较粗的发布计划中建立的假定进行细化。敏捷规划分为两个阶段的过程：

第一个阶段产生发布计划，边界粗糙并具有总体的不确定性。

第二个阶段产生迭代计划。迭代计划仍有一些粗糙的边界，也存在一些不确定性， 但由于是在开始一次新的迭代的同时建立它的迭代计划，所以，迭代计划会比发布计划详细得多。

一周的时间安排

采用 2 周一次的迭代，在星期五开始，星期四结束。星期五被用来进行迭代回顾和计划下一次迭代。新的迭代在接下来的星期一才真正开始。这样做的好处在于，不用再担心像以前用星期一作为回顾和计划的日子一样，星期一整天都要开会。

14.3 速度驱动的迭代计划

迭代规划的方法有两类：速度驱动的(velocity-driven)和承诺驱动的(commitment-driven)。这两种方法可以在不同程度上进行混合。

速度驱动的迭代计划包含的步骤如下：

一，团队共同调整优先级。在前一次迭代中可能会了解到一些会改变用户故事优先级的东西。

二，确定接下来这次迭代的目标速度。

三，团队选择一个迭代目标。迭代目标是对他们希望在接下来这次迭代中完成的工作的概括说明。

四，根据迭代目标，团队选择具有最高优先级的、支持该目标的用户故事。根据需要选择用户故事，直到选择的故事的理想人天或故事点总和等于目标速度。

五，把每个选中的故事都分解成任务，对每项任务分别进行估算。

14.3.1 调整优先级

无论是用故事卡堆叠，还是在电子表格中排序，具有最高价值的用户故事位于最上面，而价值最低的用户故事位于最下面。在每次迭代开始时都从这个优先级列表的顶端选取用户故事。

优先级变化的来源之一是迭代评审会议(iteration review meeting)，通常在每次迭代结束后召开。

用户故事和主题的优先级是根据它们对产品的经济价值、成本、团队可以学到的知识的量和重要性，以及减少的风险量来确定的。理想情况下，团队应该先等待前一次迭代评审会议结束，再讨论接下来一次迭代的优先级。建议把优先级会议安排在一次迭代结束前 2 天的时间。此时，通常已经清楚当前这次迭代是否会有未完成的工作。

产品负责人可以决定完成这些工作是否将在后续迭代中的优先考虑。产品负责人引导优先级会议，并找来所有他认为会对确定项目优先级的讨论有贡献的人。会后，产品负责人通常根据在迭代评审中发生的情况对优先级进行动态调整。

14.3.2 确定目标速度

大多数团队默认的假设是他们在下一次迭代的速度等于最近一次迭代中的速度。有些团队更喜欢使用一个变化均值，即过去 3 次迭代的平均速度。如果团队以前没有合作过，或者是新采用敏捷开发过程，他们就必须预计自己的速度。

14.3.3 确定迭代目标

迭代目标简要说明了在本次迭代期间他们想完成的工作。迭代目标是对迭代中将要完成工作的整体性陈述。它并不需要非常明确。

14.3.4 选择用户故事

产品负责人和团队选择用来组合以满足迭代目标的用户故事。在选择将要处理的用户故事时，产品负责人和团队要考虑每个故事的优先级。

14.3.5 把用户故事分解成任务

一旦选择了合适的用户故事集合，每个用户故事就要被分解成一组为了交付这一功能所需完成的任务。

1. 只包含为此项目增加价值的工作

迭代计划应该只确定那些能够为当前项目带来直接价值的任务。只要不是与开发这个产品有直接联系的任务都不应该包含到迭代计划中。

2. 尽量明确，直到养成习惯

新的敏捷团队往往不熟悉或者不能熟练地编写自动化的单元测试。项目经理应鼓励开发团队明确地指出单元测试任务并估算。一旦类似于单元测试的任务成为习惯，就可以包含在另一项任务中。

3. 会议会占据(很多)时间

团队需要在迭代计划中识别、估算并且包含与项目相关的会议任务。对会议进行估算时，一定要考虑所有参与者都需要花时间，还要考虑用于准备会议的时间。

4. 缺陷

敏捷团队的目标之一是在发现缺陷的迭代中就修复它们。任何一项任务的估算值应该包含了用于修复在实现过程中发现的缺陷的时间，否则就应该确定和估算一个独立的任务(“修复缺陷”)。建议只确定一项任务，且在该任务通过所有的测试之前不认为已经完成。应该按与用户故事一样的方法确定故障修复工作的优先级，分配到后续的某次迭代中。只要超出一次迭代的范围，就不再有什么故障的概念。修复一个故障和增加一个功能只是一件事的两种说法。

5. 处理依赖性

实现一个用户故事常常会依赖于首先实现另一个故事。大多数情况下，这种依赖性不是什么大问题。通常实现用户故事时总是有一种自然的顺序，即有一种对开发人员和产品负责人来说都有意义的顺序。自然顺序通常就是团队对故事进行估算的时候所设想的顺序。

不按自然顺序开发会导致项目花更长的时间吗？有两个答案：也许不会，即使会也没关系。

首先，项目也许不会花更多的时间；我们所做的是把某些任务从一个用户故事移动到另一个中。不过，一旦你决定不按照自然顺序进行处理，就应该对涉及的用户故事进行重估。

其次，即使按照这个顺序处理用户故事导致项目花了更长的时间，也没有关系。因为通常不按照自然顺序来处理它们总是有更好的理由。

6. 难以分解的工作

探针(Spike)就是包含在迭代计划中，专门用来获取知识或者回答问题的任务。这个探针可以帮助团队了解他们应如何处理另一项任务，从而允许他们对它进行估算。当团队难以推测某件事时可以建立两项任务：一个探针和一个占位符。占位符中是对持续时间的猜测。

14.3.6 对任务进行估算

对任务的估算是以理想时间来表述的。通常最佳的估算来自于将要处理这项工作的人，但在敏捷开发项目中对任务的估算应该是一项团队活动。原因有 4 个：

一，由于在迭代计划中并没有把任务分配到个人，所以就不可能让那个特定的将要完成这项工作的人来做出估算。

二，即使我们预期特定的某个人来负责某项任务，而且即使他对这项任务有最充分的了解，也不是说其他人就不能做出任何贡献。

三，听到预期需要多长的时间来完成某项任务，常常可以帮助团队发现对用户故事或是任务的误解。

四，若由负责这项工作的人做出估算，他的自尊心可能会防碍他在以后承认做出的估算不正确。若估算是共同做出的，就不会存在这种对承认错误的不情愿。

1. 一部分设计就够了

在建立任务和估算值列表时进行一些设计是必需的。当然，在计划一次迭代时，不需要在功能的设计上走得很远。

有两种类型的设计讨论是必需的也是合适的：

一种是产品负责人讨论产品设计、应该把功能实现到何种程度，以及应该如何把它显示给用户；

一种是开发团队讨论如何实现所需功能的不同做法。

迭代计划只是对完成功能所需工作的推测，若进入迭代后发现确定的任务不正确，就抛开最初的任务，创建新的任务；若估算值不正确，就划掉它写上一个新值。

2. 任务的合适大小

建立的任务应该具有适当的大小以便每个开发人员大致能够每天完成一项。更大的任务常常是有必要存在的，但通常应该把更大的任务看成占位符，用于在有了更深入的了解后尽快增加一项或多项任务。

注意，并不需要用等于最初估算值的任务卡片来替换原始的卡片，即替换它的任务的估算值之和可以大于也可以小于原始估算值。

14.4 承诺驱动的迭代计划

承诺驱动的迭代计划方法的步骤：

一，调整优先级。

二，确定迭代目标。

三，选择一个要加入到迭代的用户故事。产品负责人和团队选择支持迭代目标的具有最高优先级的故事。每次只选择一个用户故事是因为在把每个故事分解成任务并进行估算之后，团队需要确定他们能否承诺在迭代中交付这个故事。四，要求团队做出承诺，直到无法再承诺更多的用户故事时完成迭代规划。

要求团队做出承诺

敏捷团队成功的关键因素之一是由所有团队成员共同做出统一的承诺。在迭代计划会议中，项目经理通常这样问团队：你们可以承诺交付我们已经讨论过的特性吗？而不是问：你们可以承诺交付我们已经确认的任务吗？每次把一个用户故事分解成任务并对这些任务做出估算，项目经理都应问团队能否做出承诺。当不能再承诺时，也许他们会选择在结束前放弃一个用户故事，并用一个稍小的故事来代替它。

1. 对估算值求和

团队要确定他们能否对一组用户故事做出承诺的最好办法是把对任务的估算值求和，看看它所代表的工作量是否合理。虽然在某些任务上还存在大量的不确定性，但对估算值求和总可以在一定程度上预示总工作量。在对一次迭代的工作做出承诺之前，团队需要看一下任务，感觉一下它们所代表的工作量分布对团队成员所具备的各种技能是否合适。团队应该首先尝试找到可以更好地共享工作职责的办法。关键在于让团队中的每个人都有责任做出他们力所能及的贡献，而不管这是不是他们的专长。

2. 维护与承诺

当团队承诺在迭代中完成一组用户故事的时候，他们需要同时考虑在维护和支持工作方面的负担。这里所说的维护和支持活动指的是那些无法预测但是占据了很多团队的一部分时间的工作——支持一个产品网站或者数据库、接听关键客户的支持电话或第一层的技术支持等。大多数情况下，团队无法很准确地预测接下来要承担的支持工作负荷。如果在一次迭代中支持和维护工作的负担超过了预期值，团队可能就无法实现他们的承诺。他们只能在支持和维护负担比预期轻的迭代中超越做出的承诺，才能弥补这个问题。

14.5 我的建议

速度驱动和承诺驱动的迭代计划方法都是可行的方法。不过，作者更建议承诺驱动的方法。虽然速度在发布计划中扮演了关键的角色，但它在迭代计划中并非扮演同样重要的角色。原因有两个：

一，速度是对粗粒度估算(故事点或理想人天)的度量，它在计划短周期时间的迭代中的工作时是不够精确的。

二，团队会需要每次迭代完成 20~30 个用户故事才能把故事点或理想人天估算中的误差平均掉。

由于在单次迭代中完成的用户故事数目太少，不能把这个差异平均掉，因此建议在计划迭代时不使用速度。但是，因为在发布的进程中确实可以平均掉这些差异，所以速度对于发布计划还是非常有效的。

14.6 任务估算值和故事点的联系

项目中的每个成员都应该记住，即使最初的高层次估算值一样，某些故事也可能会需要比其他故事更长的时间。

只要在迭代中有足够数量的用户故事来把这些超出常规的任务平均掉，就不会有问题。

14.7 小结

迭代计划比发布计划更仔细地审视单次迭代中的特定工作。典型的发布计划是 3~9 个月，而迭代计划所看到的范围不会超出一次迭代。

迭代计划会将发布计划中相对大的用户故事分解成任务。对每项任务，都要按照完成该任务所需要的理想小时数进行估算。

概括起来有两种进行迭代计划的方法：速度驱动的方法和承诺驱动的方法。

---

版权声明

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

---