Scrum介绍系列9--- 产品发布计划(release plan)

Sprint 持续直至产品所有者决定产品已经可以准备发布，此时会有“发布Sprint“来进行最后的整合和发布产品前的检测。如果开发团队一直贯彻很好的开发方法，不断地重构和持续集成，在每一Sprint 中的有效测试，就不会存在许多遗留问题需要清除。

有这样一个问题有时会被提到，是怎样在一个迭代的模式中产生长期的发布计划。在一个项目的起始阶段，开发团队会作出粗线条的发布计划；他们不可能预先得知工作的结果，其重点是创建一个大体的计划提供给项目发展一个大体的方向，并阐明交易决策如何形成（比如范围相对于进度表）。以此作为路标来指引你向目标迈进；在行程中你实际挑选的路程和所做的决策都是途中决定的。


有一些产品发布是以日期界定的；比如：“我们会在11 月10 日的产品展示会上发布我们项目的2.0 版。“在此种情况下，开发团队会在现有的可利用时间内完成尽可能多的Sprint（构建尽可能多的功能）。有些产品要求某部分构建完成才可以说明整个产品的完成，产品不会在这些要求满足前被发布，无论周期长短。Scrum 强调在每一Sprint 中都生产出可以随时交付的编码，开发团队可以进行中间的发布，使客户可以更快的收到产品的效益。


大多数产品所有者会选择一个发布方式，但是会通知其他的——比如，他们会决定发布日期，他们会与开发团队成员一起对Backlog 中项目的完成日期做一大体的估算。在“固定价格/固定日期/固定交货期”的情况下——比如，合同制开发——在这些变量中至少有一个内部存在缓冲区，可以容许不确定因素和变更；在此方面，Scrum 于其他的开发方法并无区别。