敏捷产品管理之发布、迭代计划

上篇我带你从理解产品 Backlog 最好的形式 Story 开始，经过建模、搜集、编写、估算这四个步骤，编写出有效并且粒度合适的 Story 来帮助团队成员在理解需求上达成一致。让“一张卡片”发挥出它的洪荒之力，快速挖掘需求，理解需求。本篇我会带着你用编写好的 Story 来制定发布计划、迭代计划，并且在过程中进行有效测试和监控。

发布计划

当 Scrum 团队按照 Sprint 的方式进行迭代交付的时候，他们更加关注的是发布，而不是项目。那么什么是一个发布呢？简单的说，它就是一个开发团队交付一个可以工作的软件给团队外部的人使用，以满足他们的某个目的。当你交付一些内容给下游的QA验证团队来做测试时不是一个发布，当你把你的软件功能和其他团队开发的功能进行集成的时候不是一个发布。当你告诉其他人：“来吧，你现在可以使用它了”，这叫做一个发布。一个发布是多个Sprint 集中交付工作的一个成果，这常常是对市场、业务和客户产生影响的标志性的时刻。
那制定发布计划的步骤有哪些呢？我来带着你一步步实践

1. 确定优先级
   大部分软件项目以每 2 到 6 个月作为一个发布周期，一般以产品开发线路图开始规划发布。它可以是未来几个发布要关注的重点，可以是之前我在产品 Backlog 里讲到的“主题”，也可以是必须包含的功能，那如何排列出优先级呢？
   这里推荐莫斯科规则（ MoSCoW ) 排列优先级的方法：
   必须有（Must ) ：指系统的基本功能
   应该有 ( Should