上一章：第5章 自组织：敏捷团队如何开展自组织？

在上一章，我们介绍了如何建立自组织团队，本章我们将介绍如何制定一份好的迭代计划。 经常有人问我，敏捷核心是“拥抱变化”，那为什么要做计划呢？这是因为敏捷和所有项目管理都一样，我们需要行动方案来指导我们达成未来的目标，计划可以帮助我们有序地推进，但是敏捷的计划频度相较于传统开发更加高频，敏捷的计划更加灵活，我们称之为迭代计划。

在敏捷中，我们要将上一个迭代中用户的反馈加入本次迭代当中，也就是说敏捷落地是一个闭环，从最初的演进阶段，根据待办事项列表选择优先级最高的任务，接着实施阶段去完成该任务，然后反馈阶段收集用户体验得到他们最真实的想法，最后优化阶段根据之前的反馈进行优化，这四个阶段周而复始帮助我们的产品趋向最佳，不断提高用户的满意度。在整个过程中，迭代计划用来帮助我们更加高效地推进。

知道了这些，我们还要复习一下之前提到的“时间盒”概念，时间盒是一种管理方法，即在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。一个好的迭代计划应该是在时间盒内尽可能排进价值最高的代办事项。

1.制定迭代计划

具体制定迭代计划时，我必须要考虑到以下这些方面。

1.确定迭代周期，这通常由团队自行决定，一般在 1~4 周之间。迭代周期主要取决于两个因素：敏捷成熟度（指团队敏捷实践的能力）和自动化程度，这两种因素程度越高，迭代周期越短，反之越长。

2.确定一个迭代内的关键工作项，比如什么时间进行需求评审、什么时间测试。

3.固定关键工作项的发生时间，比如我们用两周迭代，然后在第二周的周一进行需求评审，周二开始测试。我们通常用表格将固定关键工作项的发生时间列出来，放在团队都能看到的位置，大家需要共同遵守。

4.培养团队的工作节奏感，大家根据上述表格来安排每周固定的会议，如需求评审会、迭代回顾会、迭代计划会，等等。

5.如果待办事项的紧急程度不一致，可以在一个时间盒中设置多个发布节点，但是一般不超过 2 个。如果有紧急需求，需要在迭代内进行发布，我们也可以灵活调整，让其发布，原则上不超过2个，因为迭代内太多次发布，整个节奏就会乱掉，那迭代节奏也就没有意义了。

2.迭代计划会议

既然迭代计划如此重要，我们在实际项目推进中就需要进行相应的迭代计划会议，与团队成员共同商议出一份大家都认可的迭代计划才可以事半功倍。那么我们该怎么举办一场迭代计划会议呢？ 我们要考虑到这几点因素。首先是确定会议目的，即通过会议我们要明确即将要开展的工作内容，讨论明晰待办事项的相关信息；其次是确定会议参与人，一般 Scrum Master 是组织者，PO 和 跨组织职能团队均要参与；接着是会议议程，这个过程比较相对复杂一些，我们稍后会详细说明；再次是通过会议确定迭代目标，我们可以把此目标放在团队显眼处同步；最后是输出，即将结果做成迭代代办事项列表，这其实是待办事项列表的子集，因为它是从待办事项中选出的优先级最高的事项。

2.1会议议程

通常情况下，迭代计划会议的议程分为两个部分，What 和 How。 我们先来看第一部分，What 就是明确要做什么。在这个部分我们需要换位思考，站在用户的角度，作为用户去使用产品，设身处地地从场景中提炼用户的痛点，这个过程也叫作讲故事。 我们知道在待办事项列表中，PO 会使用 MoSCoW 法则对任务来进行基于客户价值的优先级排序。此时我们就要从待办事项列表中，选出既能满足用户痛点，同时优先级较高的用户故事，然后支持用户场景落地，也就是实现这个功能。

知识补充，MoSCoW 法则：
Must：必须要做的—功能集或Feature（特性）是系统的基础，没有了它们，系统将无法work或没有价值。
Should：应该做的—我们应该有的功能，这样子系统才可以正常使用，如果没有他们，系统将非常非常难用。
Could：可以做的—产品的附加值，加分亮点项。
Would not：不要做的–这个产品不需要的功能。
值得注意的是：待办事项中标为 Must、Should 的事情我们要保证完成，Could 优先级的我们争取未完成 ，在发生重要变更的时候，我们牺牲优先级为 Could 乃至 Should 的事情保证变更。

其次，How 就是明确我们怎么做，在这个部分我们需要先对选出来的用户故事进行工作量估算，我们可以采用故事点数和理想人天数来估算工作量；然后分解任务，遍历所有的用户故事，将其分解成团队成员可执行的任务，如分成前端任务、后端任务、联调任务、测试任务等，用户故事分解遵循谁认领谁分解的原则；最后团队承诺，任务分配到成员后，每次成员要承诺保质保量，尽可能做到不延期完成任务。

2.2两种估算方式

理想人天数估算，这是一种个体估算。具体是指假设没有任何突发事件的理想情况下，一个开发人员完成该故事所需的工作量。这种方式实施起来比较简单，完成一轮估算所需时间较短，因为每个人都很熟悉自己的工作效率，所以这种估算方式比较主流。
但是这种方式没有考虑到差异化，就像小马过河一样，每个人的工作效率是不同的，一旦估算的成员与执行的成员不是同一个人，那执行时的工作量偏差可能很大。

故事点数估算，这是一种集体估算，敏捷更推荐使用。具体是这样操作的：

1. 建立团队共同认可的估算基准值，即团队对同一个需求要有一致的理解。这个基准值可以是完成一个需求的页面数，也可以是对数据库的增删改查次数，也可以是完成操作的步骤，一般完成单位功能基准值为 1；
2. 对同一个需求，每位成员都要给出自己的评估值，然后通过估算扑克方法同时呈现，因为是相对估算，我们基于斐波那契数列，把故事点数设置为 0，1，2，3，5，8，13，20，40，60。
3. 估算最低和最高的成员说明自己估算的理由。比如 A 认为这个需求点数是 60，因为 需求里涉及很多算法，而团队之前没有做过任何算法的工作。 而 B 认为需求点数是 5，因为他知道有第三方的算法工具可以直接引用。综合这些因素，团队考虑到 B 想法的可行性，最终决定对该需求评估是 5 个故事点；
4. 对同一个需求进行 2 到 3 轮估算，通常用 5 分钟左右就可以最终确定该需求的估算；
5. 重复第 2、 3 步，直到估算完本次迭代所有需求的工作量。

在这个过程中，大家都参与其中，所以最后的结果集合了各方视角，在团队建立了一致的理解，更重要的是增加了准确性。但是这种估算时间较长，两周迭代一般估算得花掉两个小时左右。
根据我的经验，对于刚接触敏捷的团队，可以使用理想人天进行估算。对于运用敏捷一年以上的团队，可以尝试着用故事点估算，这样团队更容易对需求达成一致。

3.总结

本章我们介绍了如何制定敏捷迭代计划。下一章将介绍如何执行计划以及监控执行过程。如果你有敏捷管理方面相关的疑问，欢迎你在留言区留言与我一起讨论，本系列文章会持续更新，请关注博主以待后续。