我们目前在工作中使用敏捷环境。我的任务之一涉及制定发布时间表。其中一部分是提供一个时间框架，说明项目从开发环境到登台再到上线需要多长时间。
对于是否需要制定这样的时间表，我有相互矛盾的想法。
首先，我们正在快速进入持续集成/持续交付环境，在该环境中，当对代码库进行更改时，应用程序会在所有环境中进行测试。因此，没有时间框架，但事情应该“刚好”可部署。 (嗯，我们总是需要一点意外事件，因为再好的计划也可能会出错)
如果敏捷产品开发环境中的发布管理需要，任何人都可以引导我朝着正确的方向发展，以了解处理此类时间表和时间框架的最佳方法。
问候，
史蒂夫
最佳答案
Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.
首先，Scrum 框架指南从未指导您不要制定发布计划或时间表。是什么导致你产生矛盾的想法？我想知道导致您陷入这场冲突的根源。
创建发布计划的最佳方法如下(这可能需要一周左右的时间，具体取决于项目的大小):
将利益相关者召集到一个房间，并根据他们的指导将 EPIC 用户故事写在黑板上。 EPIC 用户故事应包括最终产品愿景。 (如果已经完成则忽略)
列出用户类型。(如果已完成则忽略)
将 Epic 用户故事分解为越来越小的用户故事 block ，直到它们小到足以在冲刺中完成。(如果已经完成，请忽略)
要求 Scrum 团队的产品负责人对未提交的待办事项列表中的故事进行优先级排序 还要相当快地进行某种形式的工作量估算，不要浪费大量时间进行估算.
从利益相关者处获取项目的目标结束日期或上线日期。
将从现在到结束日期的时间范围划分为多个版本。询问利益相关者哪些功能需要在何时交付，并在其中包含适当的用户故事，并将其称为发布。如果需要，您还可以提供这些发布主题。
发布计划现已概念化。 之后，将其绘制在白板上或将其放在每个人都可以看到的可见且透明的位置 - 将用户故事卡添加到适当的版本中。
现在您的初始发布计划应该已准备就绪
实现想法:
组建专门负责运营事件的 Scrum 团队。他们可以遵循 Scrum 或看板会更好。
当开发团队将“可交付产品”上架时，运营看板团队可以根据发布计划执行部署和发布分支等任务。
这样，开发团队就不会真正关注发布计划或工作，只有运营团队负责。开发团队只专注于冲刺工作，确保正确的用户故事以正确的顺序出现在正确的版本中将是产品负责人头疼的问题。方向将由利益相关者给出。
说实话，你真的不需要自己做任何事情，一切都在利益相关者和 PO 手中，我不知道哪里有什么大惊小怪的？
希望你能看到这张照片。
关于deployment - 敏捷环境中的发布时间表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3940783/