敏捷环境中的发布时间表 [关闭]

Question

我们目前正在工作中使用敏捷环境。我的任务之一是制定发布时间表。其中一部分是提供一个时间框架，说明项目从开发环境到登台然后上线需要多长时间。

对于是否需要制定这样的时间表，我有不同的想法。

首先，我们将快速进入持续集成/持续交付环境，在对代码库进行更改时，在所有环境中测试应用程序。因此，没有时间框架，但事情应该“只是”可部署的。 （嗯，我们总是需要一点应急，因为最好的计划总是会出错）

如果在敏捷产品开发环境中的发布管理中需要，任何人都可以指导我如何处理此类时间表和时间框架的最佳方式。

问候，

史蒂夫

Answer 1

这是一个非常繁重的问题，具体取决于您的公司。我首先要问，你为什么要使用 3 个环境和持续集成（你的理由很重要）？您是否正在执行自动化测试？你的代码分支是如何设置的？您是针对某些功能发布的，还是只是例行维护修复？

回答这些问题会让您了解为什么需要发布，以及应该如何去做。

例如，如果您只有一个用于集成和执行自动化测试的暂存环境，那么拥有一个运行持续集成测试的单独代码分支就不够了吗？

如果登台是为了执行某种用户接受，贵公司是否有专门的测试团队或者他们是敏捷团队的成员？

正如您所说的那样，如果始终集成和测试代码，那么除非您不确定功能的实际“完成”条件，否则为什么需要时间表并从一个环境迁移到另一个环境？我的意思不是说您不确定该功能是否正确编码，而是您担心它会引入其他错误吗？它会与已经在生产中的代码很好地集成吗？从根本上解决问题。不要仅仅因为你认为你应该有 X 环境或测试应该在另一个组中而这样做。也许这些问题的解决方案可能是相应地调整“完成”的定义。

正如您所见，有很多很多因素可以让您的组织与众不同。没有一种正确的方法来回答这个问题，只有您愿意接受的权衡。

我发现，在多个环境中，由不同层级的人员组成的团队往往会产生反敏捷和适得其反的效果。最好的办法是分析您的担忧，并尝试找到解决它们的方法（例如扩大“完成”的定义，或者将各种组织分解并放入团队中，尽可能多地消除环境并简化过程等）。这在您的组织中可能无法实现，因此您可能不得不权衡取舍。

Answer 2

如果在敏捷产品开发环境中的发布管理中需要，任何人都可以指导我在处理此类时间表和时间框架的最佳方式上的正确方向。

首先，Scrum 框架指南永远不会指导您永远没有发布计划或时间表。是什么导致你产生矛盾的想法？我想知道导致您发生这种冲突的根源。

创建发布计划的最佳方式如下（这可能需要一周左右的时间，具体取决于您的项目规模）：

1. 让利益相关者进入一个房间，并在他们的指导下将 EPIC 用户故事写在板上。 EPIC 用户故事应包括最终产品愿景。 （如果已经完成则忽略）

2. 列出用户的类型。（如果已经完成则忽略）

3. 将 Epic 用户故事分成越来越小的用户故事块，直到它们小到可以在 sprint 中使用。（如果已经完成，请忽略）

4. 要求 Scrum 团队的产品负责人对未提交的待办事项列表中的故事进行优先级排序 还要相当快地进行某种形式的工作量估算，不要浪费大量时间估算.

5. 从利益相关者那里获取项目的目标结束日期或上线日期。

6. 将从现在到结束日期的时间范围划分为版本。询问利益相关者哪些功能需要在何时交付，并在其中包含适当的用户故事，并将其称为发布。如果需要，您还可以提供这些版本主题。

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

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

实施思路：

1. 组建专门针对运营活动的 Scrum 团队。他们可以遵循 Scrum 或看板会更好。

2. 当开发团队将“可交付产品”上架时，运营 Kanaban 团队可以根据发布计划执行部署和发布分支等任务。

因此，这样一来，开发团队就不会真正专注于发布计划或工作，而只是运营团队这样做。开发团队只专注于 Sprint 工作，确保正确的用户故事以正确的发布和正确的顺序出现是产品负责人头疼的事情。方向将由利益相关者给出。

说实话，你真的什么都不需要自己做，都在利益相关者和PO的手里，不知道哪来的大惊小怪？？

我希望你能得到这张照片。

Answer 3

如果您目前正在使用敏捷环境，您应该查看Agile estimating and Planning book 以获得一些建议。本书还包含有关发布计划的小章节。

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

但请记住，三种力量也适用于敏捷。功能集、发布日期和资源之间存在直接关系（+ 有时也提到第四种力量：质量）。推动其中一种力量总是会推动其他力量。它通常被建模为等边三角形（或正方形）。

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

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

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

Answer 4

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

有了维护良好的产品待办列表，就可以很容易地制定发布计划。我通常计划一年发布三到四个版本。

我喜欢 Scrum 的地方在于，我可以在每次迭代后发布。

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