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

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

发布计划

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

1. 确定优先级
   大部分软件项目以每 2 到 6 个月作为一个发布周期，一般以产品开发线路图开始规划发布。它可以是未来几个发布要关注的重点，可以是之前我在产品 Backlog 里讲到的“主题”，也可以是必须包含的功能，那如何排列出优先级呢？
   这里推荐莫斯科规则（ MoSCoW ) 排列优先级的方法：
   必须有（Must ) ：指系统的基本功能
   应该有 ( Should ) ：很重要但短期内有替代解决方法的功能
   可以有 ( Could ) ：如果没有时间可以不予考虑
   这次不会有 ( Won’t have this time ) ：客户期望拥有但同时承认需要在后续发布中实现

这里需要考虑面对高风险故事和有价值的故事如何权衡。我之前讲过风险驱动开发可以让我们尽早的消除风险带来的不确定性，但是敏捷宣扬先做最有价值的部分，这样可以使项目尽早发布，提供最有价值的功能，所以在高风险和有价值之间，优先选择价值最高的需求并且充分考虑到它的风险因素。

2. 选择 Sprint 长度
   确定完优先级之后，团队所有成员需要一起选择一个适合的 Sprint 长度，一般建议1～4周，一旦固定了 Sprint 长度，就避免在项目实施期间随意更改。
   
3. 从 Story 到工期
   这里要说一个概念 — 团队速率，指团队一个 Sprint 能完成的工作量。前1～2次 Sprint 先进行观察，粗略计算出不受干扰的环境下团队平均能完成的 Story 数量。如 PO 已经排好所有 Story 的优先级，并且累计卡片数量是 100个。如果经过几次 Sprint 观察，团队速率是25，那计划经过4轮 Sprint 可以发布。这里需要注意三点：

• 速率不是人天，是经过估算的 Story 规模（上篇估算 Story 有具体讲解），比如一个 Story 估算了 1 个故事点，实际花了 2 天完成，本次 Sprint 预估完成 3 个这样的故事点，那团队速率是 3 ，而不是 6 。
• 速率是团队内部衡量工作量的标准，不与其他团队做比较，因为每个团队对于估点的单位、规模是不一致的。
• 速率是实际完成的 Story ，不是列在 Sprint 计划里未完成或者完成一半的点数。比如本次 Sprint 预计完成 3 个故事点，实际前两个故事点全部完成，最后一个故事点只完成了一半，那团队实际速率是 2.5 ，而不是 3 。

4. 创立发布计划
   最后一步将 Story 按照优先级分别分配到每个 Sprint 中，这里建议将发布计划钉在墙上。这样可视化的方式让团队成员每天能看见。
   注意，不要迷信发布计划！如果在 Sprint 的过程中获得任何新的信息，应该不断调整期望和计划。
   

迭代计划

迭代计划是发布计划的进一步计划，但只在 Sprint 开始是才开始做迭代计划。Sprint 是以功能为纬度，而发布计划是以时间为纬度。这里要引入一个敏捷里的重要实践 - Spint 会议，即整个团队通过举行 Spint 会议来为下一轮 Sprint 做计划，会议的内容包括：

1. 讨论故事
   会议的输入是已经排好优先级的 Story 集合，团队成员可以根据自己的想法对优先级进行讨论。流程是 PO 根据优先级顺序将 Story 依次将给开发人员，开发人员可以进行提问，直到全员统一理解，并且可以从中分解出任务为止。
2. 从 Story 分解任务
   很多人会问我，为什么要做任务分解，把 Story 继续细分成更小的故事不就好了么？在我看来，分解任务其实是敏捷即时设计（just in time design)中的一次短脉冲,它取代了 Waterfall 模式前期的设计阶段。它不是用户价值的功能描述，是作为开发人员的待办事项。这里需要注意一点，任务卡片的模式可以不参照 Story 卡片的格式，只要能表示出完成 Story 的最快途径就好。
3. 开发人员承担每个任务的职责
   开发人员可以在分解任务之后对任务进行认领，理想的任务卡片标准是一个任务卡片对应一个责任人一个人天，责任人最好是写在卡片旁边，即使是结对编程，每个卡片也需要有一个责任人。
4. 讨论过所有故事，开发人员单独估计承诺他们的任务
   每个开发人员对认领的任务进行估算，如果 Sprint 时间内估算超过了开发人员所能承担的工作量，有以下几种选择：请求团队成员接受一些任务；与 PO 讨论，放弃其中一个 Story （或者是分解后的一部分）

小结

本篇我们将项目分成一系列 Sprint 来做发布计划，每轮 Sprint 中安排一定的 Story 和任务。一轮迭代完成的故事点就是团队的速率。下篇我带着大家详细了解怎么根据不同速率的可视化管理工具，测量并监控速率。