敏捷发布计划：注意事项
4.73/5 (6投票s)
以下是一些关于敏捷发布规划的注意事项。
引言
成为一名产品经理并非易事。我管理着一个电子学习产品，并且通常在开发过程中遵循敏捷的 Scrum 模型。相信我，每次发布后，我都会问自己一个问题：我还能做些什么来让这次发布更成功？以下是一些关于敏捷发布规划的注意事项。
敏捷发布规划注意事项
发布规划是整个 Scrum 方法论中最具挑战性的任务之一。虽然有挑战，但它是整个敏捷开发过程中最重要的一部分。发布计划（如果做得正确且具有战略性）能够清晰地设定需要开发的内容及其时间表。但这里的关键是：时间表比需要开发的内容更重要，还是反之？最终，答案变得非常难以捉摸。尽管发布计划有助于产品负责人和开发团队成员了解需要开发什么以及在什么时间段内完成，但问题是他们是否真正知道“必须”开发多少，以及发布一个可发货的产品需要多长时间？
发布规划：目标
战略性的发布计划就像一个火炬，团队可以在进步过程中跟随。发布计划的总体目标应该是为产品路线图和团队实现这一目标的承诺奠定基础。
详尽的发布计划是针对可能从会议室大小到市场标准等后勤事务的规划。目标应该是减轻风险因素，能够就我们的承诺达成一致。在规划发布时，肯定还有其他因素需要考虑。其中一些如下：
- 团队的现状
- 团队速度
- 产品待办事项列表
- 现有问题
- 计划定义
- 优先级排序
- 团队的估算
- Logistics
- 利益相关者的存在
- 依赖项
- 清晰度
- 视觉
- 商业价值
- 沟通计划
最后但同样重要的是：你想通过这个计划解决什么目的？
方法
有两种方法可以规划你的发布，每种方法既有区别又是同一枚硬币的两个面。第一种是“固定时间表”，第二种是“固定工作范围”。这些方法（如果采用并正确实施）将解决我们在本文第一段中遇到的许多问题。
1. 固定时间表
这种固定时间表/截止日期/日期方法定义了一个界限，你不能超出这个界限进行开发，并且你的项目必须在此日期前完成。在设定的日期上没有延期或协商的余地。所以如果你知道你可能会失败，那就快速失败。不要在发布计划中包含不适合的用户故事。
约束和灵活性
虽然在时间表上没有协商余地，但我们在行动项的灵活性上获得了一些空间。项目团队将承诺一个固定的日期，但可能不会承诺在发布结束前完成 100% 的功能基线。在此方法中，目标应该是尽可能多地完成工作，并在截止日期前冻结开发，以便产品仍然处于可发货状态或可发布状态。剩余的工作或部分用户故事可能会移到下一个规划和开发周期。此方法不允许你在遗漏产品的主要部分或功能方面过于灵活。所有主要的、关键的功能都应得到满足，以增加发布产品的价值。
2. 固定工作范围
另一方面，这种方法有助于确定在发布中实际需要冻结的工作。它规定了在发布中必须包含哪些功能，而不考虑严格的最后期限。在这种情况下，时间表可能会延长或会变得灵活，但实际的工作项和功能不能协商。当产品功能较少或需要开发一项主要功能来为产品带来实际价值时，可以采用此方法。
约束和灵活性
虽然你在时间表上有灵活性，但其弹性应该是合理的。如果开发周期约为 12 周，那么延长时间最多应限制为额外一周。超过这个时间可能会再次引发对已发布计划的质疑。当你以敏捷模型进行开发时，普遍的理解是可能会出现延误，但同样，在这种方法中包含缓冲区应该是规划的一部分。
3. 固定时间表和固定工作范围
这是你作为产品经理必须做出的决定。你可以在接受挑战方面保持灵活性，但另一方面，你也需要坚定地对不合理的请求说“不”。
结论
前两种方法肯定有助于为你的发布奠定关键标准。发布规划的主要目的不是“什么必须完成”，而是“我们有多么确定要完成它”。我们可能无法最终构建一个完美的计划，但我们应该对最终要做的事情充满信心。发布规划的总体目标不是产出一个规划周密的文档，而是，发布计划的价值在于规划本身。保持敏捷。
参考文献
首次发布：http://elearningindustry.com/agile-release-planning-considerations