发布规划会议是确定发布或改变产品、可交付物或价值增量的高层级计划。如图7-11所示。

图7-12发布规划（图表来自PMBOK第七版）

适应型进度规划会采用增量规划的形式，基于价值路线路制订计划，包括产品愿景、产品路线图、发布计划和迭代计划。发布计划是价值路线图的第三阶段，为团队提供了一个中期目标。一个发布是多个迭代集中交付工作的一个成果，这常常是对市场、业务和客户产生影响的标志性的时刻。制订发布计划一般有四个步骤：

（一）确定优先级

大部分项目以2~6个月作为一个发布周期，一般以产品开发线路图来规划发布。它可以是未来几个发布要关注的重点，可以是产品待办列表中的主题，也可以是必须包含的功能。如何排列出优先级呢？莫斯科法则（MoSCoW)是一种常用于排列优先级的方法。

MoSCoW优先级排序法，是在项目管理、软件开发中使用的优先化技术。以便开发人员、产品经理、客户对每个需求交付的重要性达成共识。Mo-S-Co-W，是四个优先级别的首字母的缩写，再加上O以使单词能够发音：莫斯科。

（1）必须有（Must）：指系统的基本功能。如果不包含，则产品不可行。Must Have的功能，通常就是最小可行产品（MVP）的功能。比如微信的聊天信息、通讯录、朋友圈等。

（2）应该有（Should）：这些功能很重要，但不是必需的。虽然“应该有”的要求与“必须有”一样重要，但它们通常可以用另一种方式来代替，去满足客户的要求。

（3）可以有（Could）：这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交货时间紧张，通常现阶段不会做，会挪到下一阶段做。

（4）这次不会有 ( Won’t have this time ) ：不会被计划到当前交货计划中。“不会有”会被要求删除，或重新考虑。

为什么要在项目管理中使用MoSCoW法则呢？因为项目是由一群临时的组织在时间、成本、范围约束下进行的一项临时性工作。人性总是贪婪的，项目管理亦是如此，做加法容易，做减法难。而一些失败的项目，往往死于范围蔓延，常常一开始便人为地、不假思索地加入很多功能，美其名曰“全面”，最终都做不好，发起人、项目组、用户都苦不堪言。目标太多，时间紧，配置跟不上，团队的注意力也分散了。

（二）确定迭代长度

确定完优先级之后，团队所有成员需要一起选择一个适合的迭代长度，一般建议1~4周。一旦固定了迭代长度，项目实施期间就不能随意更改。一个发布包含两个或多个迭代。如图7-12所示。

图7-13 迭代长度

（三）从用户故事到工期

这里要说一个概念——团队速率。团队速率，指团队在一个迭代中能完成的工作量。前1～2次迭代进行观察，粗略计算出不受干扰的环境下团队平均能完成的Story数量。经过2~4次迭代速率稳定后，这个迭代完成的用户故事数量就是团队速率，从而大致推算出工期。

注意，速率是团队内部衡量工作量的标准，不与其他团队做比较，因为每个团队对于估点的单位、规模是不一致的。

（四）创立发布计划

将用户故事按照优先级分别分配到每个迭代中，建议不要把发布计划保存在电脑或者某个系统里，最好以可视化的方式展示出来，让团队成员每天都能看见。如果在迭代的过程中获得任何新的信息，应该不断调整期望和计划。