Handbook of ScrumMaster 学习笔记 二
上一章简单介绍过Release Planning，这一章主要介绍这一项。非敏捷开发流程是基于对整个项目的范围，预算和结束时间进行预测，这样的方式是不能满足复杂的技术项目的需求，因为这样的项目是经常会改变需求和产品方向的。没有人能够在这种负责项目开始前百分百的预测所有的需求和开发范围，这些会随着团队开发的进程而逐渐改变，因为团队在进程中会发现很多开始时没有发现的问题或者需求。基于敏捷开发的思想，会把一个产品的开发分成若干个release，这样可以及时针对发现要做的改变进行调整。
A Release Planning是对一个release的计划和对产品或项目方向的定义，一个release通常包括几个sprint, 可以从1个月到3个月的时间范围。所以它是较为长期的开发计划也是对产品的不断调整。
- 从Product Backlog开始
- Release Planning
- 如何引导一个Release Planning的制定
从Product Backlog开始
前一章说过product backlog是优先级排序的特性或者工作列表，用于实现一个产品。这个列表是可以随时添加新的项目，因为总是会可能有新需求添加到一个产品中的。Product owner（可能是真正的客户，也可能是内部人员，譬如产品经理）可以修改，添加和对列表进行排序。基于市场分析，产品愿景，行业分析，技术创新等等，product backlog体现了product owner对于产品最有价值的想法和特性。
Product backlog应当是product features而不是系统组件的改动更新，也就是说不要使用诸如”在数据库order_detail表里添加created_time字段”这样的语句。这里应该是从用户的角度来描述我们的产品特性或者工作的。以下是两个Product Backlog例子，大家可以想象是否使用product backlog B和相关的商业人员沟通吗？
Product backlog至少应该有3列：优先级，描述和估算（可以使用user story points这样的相对值方式），需要牢记的是Product backlog是与不同和责任的相关人员的计划和沟通工具。下表是一个包含父子关系的product backlog例子：
Release Planning
现在我们已经有了Product backlog, 那么开发团队可以基于优先级进行实现了，不过大部分的公司是需要知道大概一段时间内哪些产品特性是可以被实现的，于是我们还需要进行Release Planning。
也就是说我们要决定大概多长时间把一些新的产品特性发布给我们的客户(有可能是内部的，也可能是外部的)，这需要产品的责任人与客户(也有可能是市场部)进行沟通和讨论决定每一个Release大概的时间。一般是一个月到三个月，当然这要看产品的类型了，比如说一个地图软件我们可能随时欢迎他们有新的改变，可是如果ios每个月都有新版本并且修改了界面这就有点过于频繁了。
在我们把一个大的项目或产品分成若干Release后，我们降低了对产品整体估算的错误率，基于传统方式的项目管理会对一个产品进行一个整体估算，而显然在项目还没有开始就进行估算是会有非常大的误差的。
我们在第一章也提到过Sprint Planning的概念，一个Release可以被分成若干个更小的Sprint来进行计划和实现。但是要强调的一点是现在的产品不再是由一个人完成了，需要若干人或团队一起合作完成。这就需要在产品被完成前要进行整合，而我们的整合测试要尽早完成，这样可以尽早在整合时发现一些可能的问题或风险。这也是为什么每一个Sprint都要提交的是整合好并也完成了整合测试的成果物。我们不要冒着在一个Release最后要整合测试才发现各种问题的风险。
另外在对每个Release进行计划的时候，我们是有很多的不确定甚至不知道的事情，所以要对我们的估算能提交的特性进行一定的预留时间，这绝对不是在做一件坏事，因为基于所有人的经验开发团队是不可能100%按照计划进行的。这并不是开发团队故意拖延而是各种意想不到的事情会拖延进度，因此早一些把这些风险预估进去是对整个项目和产品负责。越是不确定性多的项目团队，越应当增加自己预留的时间。如果在实际的开发过程中，发现一个Sprint提前很多完成了所有计划的功能，则需要重新评估一下是否可以在该Sprint中加入新的特性。同时也要对团队的开发速度进行重新评估，在未来的Sprint和Release中重新计划能够完成的功能。下图为一个例子对每个Sprint设置的完成产品特性和预留时间，最后一个Sprint可以考虑为Release Sprint:
如何引导一个Release Planning的制定
首先是要做好足够的准备工作，这包括以下几点：
- 决定何时何地开会，如果大家都在一个办公地点，这就可以比较容易解决。如果相关人员在不同城市甚至不同国家，就要提前确定好时间(要考虑时差因素)，使用何种方式和技术最适合交流。
- 和产品负责人提前确定好提交产品的时间
- 和产品负责人提前准备好简单介绍一下产品的远景和整体规划，这回给产品相关的所有人员对产品有一个整体印象
- 一个Release包含多少Sprint
- 谁负责确认release是否完成(Definition of Done)
- 是否有产品实现流程
- 团队是否对自己开发速度有评估
- 如过在开发过程中发现阻碍如何通知上级
- 哪里存放product backlog, sprint backlog和燃尽图等信息
- 是否需要邀请其他产品相关人员
-
有哪些风险和阻碍
不同于传统项目经理，Scrum Master 是尽量起到协调而不是自己做过多的决定，把需要决定的问题尽量和团队讨论。主要参加的人员为Product Owner, Scrum Master, 和开发团队。在Release Planning中是不需要制定详细时间计划，这可以在Sprint Planning里完成，需要的是基于估算把开发团队能够完成的产品功能定下来。
下图为要会上要讨论项目列表示例
要强调的一点是对Release的完成的定义(Definition of Done), 一个示例为：产品特性工作正常，没有影响使用功能的缺陷(严重程度 1,2,3)，页面载入时间小于1秒钟，所有的整合测试自动完成。
Release Planning的主要成果物是release plan包括有release几个Sprint,每个Sprint完成哪些产品特性，每个Sprint开始和结束时间，风险等等。下图为一个release plan例子：