问敏捷环境中的发布时间表

EN

在敏捷产品开发环境中的发布管理中，如果需要的话，

可以用什么最好的方式来处理这样的时间表和时间框架，任何人都可以引导我的方向。

首先，Scrum框架指导方针从来不会指导您永远没有发布计划或时间表。是什么导致你有矛盾的想法？我想知道是什么原因导致了这场冲突。

创建发布计划的最佳方法是这样的(这可能需要一周左右的时间，这取决于您的项目规模)：

1. 将利益相关者召集到一个房间里，并使用他们的指导在黑板上写下一个史诗般的用户故事。史诗般的用户故事应该包括最终产品的愿景。(如果已经完成，则忽略)
2. 列出用户类型。(如果已经完成，则忽略)
3. 将史诗般的用户故事分解为越来越小的用户故事块，直到它们足够小，可以在冲刺中完成。(如果已经完成，则忽略)
4. 要求Scrum团队的产品负责人对未提交的积压列表中的故事进行优先级排序，还可以相当快地进行某种形式的工作量估计，不要浪费大量时间来确定目标结束日期或开始上线日期来自Stakeholders.
5. Divide的项目将从现在到结束日期的时间范围转换为Release。询问涉众需要在什么时候交付哪些功能，并在其中包含适当的用户故事，并将其称为Release。如果需要，您还可以提供这些版本的主题。

发布计划现在已经概念化了。在此之后，在白板上绘制它，或者将其放在每个人都可以看到的可见和透明的位置-将用户故事卡添加到适当的版本中。

现在你的初始发布计划应该已经准备好了

实施思路：

1. 组建了一个专门负责运营活动的Scrum团队。他们可以遵循Scrum或看板会更好。
2. 当开发团队将“可发货产品”放在货架上时，运营Kanaban团队可以根据发布计划进行部署和发布分支等任务。

因此，这样开发团队就不会真正关注发布计划或工作，只有运营团队才会这样做。开发团队只专注于Sprint工作，确保正确的用户故事在正确的版本中以正确的顺序进行，这将是产品所有者头疼的事情。方向将由利益相关者给出。

老实说，你真的不需要自己做任何事情，一切都在利益相关者和POs手中，我不知道哪里是大惊小怪？？

我希望你明白这一点。

我通常为管理层维护一个发布计划，该计划主要基于估计和优先排序的用户故事(我将它们分组以匹配产品的主要新功能)和速度的组合。

有了一个维护良好的产品积压，很容易完成您的发布计划。我通常计划一年发布三到四个版本。

我喜欢Scrum的原因是我可以在每次迭代后发布。

如果你想掌握你的发布管理，你将需要更多的信息，而不是从业者的回答。我强烈建议你使用this book。

如果你目前正在使用敏捷的环境，你应该在Agile estimating and Planning book上找到一些建议。这本书还包含了关于发布计划的小章节。

应该总是做一些发布计划。发布是一个目标，通常涵盖3-12个月的开发=迭代集。它描述了项目成功的目标标准。它通常被描述为预期功能和某些日期的组合。这种情况下的功能通常不是直接的用户故事，而是史诗或整个主题，因为你不知道几个月前的所有用户故事。就我个人而言，我认为发布是基于愿景的项目何时可以交付的东西。它从远景中提取高层次的期望和约束，并将它们转换为一些估计。您还可以将项目划分为几个版本。

但请记住，三种力量在敏捷中也是有效的。特性集、发布日期和资源之间存在直接关系(+有时还提到第四种力量:质量)。推动这些力量中的一种总是会移动其他力量。它通常被建模为等边三角形(或正方形)。

有不同的方法来计划发布。书中提到了一个。它基于用户故事估计，迭代长度选择和速度估计，但我对这种方法有点怀疑，因为你没有整个版本的简单用户故事，估计史诗和主题是不准确的。另一方面，高级特征定义正是您需要的三种力量。如果你没有足够的时间，你将只实现所有主题的基本功能。如果你有更多的时间，你会实现更多的高级功能。这是产品负责人在将史诗和主题划分为小用户故事时正确设置业务优先级的任务。

敏捷中最重要的部分是你很快就会知道更多。在每次迭代之后，您将对您的速度有更好的了解，并且您还将重新评估一些计划的用户故事。出于这个原因，我认为实际的估计(准确的)和重新发布的日期应该在几次迭代后计划。正如我在一次培训中被告知的那样，不应该估计努力，应该衡量努力。如果有人抱怨，给他看瀑布，问他什么时候能得到相对准确的估计？提示:几乎在分析结束之前，应该说是在项目的30%之后。

同样重要的是，您希望使用敏捷/ scrum实现什么类型的项目，以及项目将持续多长时间。一些项目是严格的预算或日期驱动的，其他项目可以更多地是功能驱动的。这可能会影响您的发布计划。对于较短的项目，您通常有较小的用户故事，并且您可以在开始时提供更准确的估计。