发布敏捷环境中的时间表

  如果在敏捷产品开发环境中的发布管理中需要，那么任何人都可以指导我在正确的方向上处理这些时间表和时间框架。 首先，Scrum框架指南从未指导您永远不会有发布计划或时间表。什么导致你有冲突的想法？我想知道导致你发生冲突的根源。 创建发布计划的最佳方式是这样的（这可能需要一周左右的时间，具体取决于项目的大小）： 让利益相关者进入一个房间，并使用他们的指导获得在董事会上写的EPIC用户故事。 EPIC用户故事应包括最终产品愿景。 （如果已经完成则忽略） 列出用户类型。（如果已经完成，请忽略） 将Epic用户故事分解为越来越小的用户故事块，直到它们足够小，可以在短跑中使用。（如果已经完成则忽略） 要求Scrum团队的产品负责人对未提交的积压列表中的故事进行优先排序也可以相当快地进行某种形式的工作量估算，并且不会浪费大量时间进行估算。 从利益相关者处获取项目的目标结束日期或上线日期。 将时间范围从现在划分为结束日期到发布。向利益相关者询问何时需要交付哪些功能，并在其中包含相应的用户故事，并将其称为发布。如果需要，您还可以提供这些版本主题。 发布计划现在已经过概念化。 在此之后将其绘制在白板上或将其放在可见且透明的位置，每个人都可以看到它 - 将用户故事卡添加到适当的版本中。 现在您的初始发布计划应该准备好了 实施思路： 组建专门针对运营活动的Scrum团队。他们可以跟随Scrum或看板会更好。 当开发团队获得“可交付产品”时，操作Kanaban团队可以根据发布计划执行部署和发布分支等任务。 因此，开发团队并不真正专注于发布计划或工作，只有运营团队才能这样做。开发团队只专注于Sprint工作，确保正确的用户故事在正确的版本和正确的顺序中是产品所有者的头疼。方向将由利益相关者给出。 说实话，你真的没有自己做任何事情，这都是利益相关者和PO手，我不知道在哪里是大惊小怪？ 我希望你能得到这张照片。     

我通常会为管理层维持一个发布计划，主要是基于估算和发布的组合。优先用户故事（我将它们分组以匹配产品的主要新功能）和速度。 通过维护良好的产品积压，您可以轻松完成发布计划。我通常每年计划三到四次发布。 我喜欢Scrum的是我可以在每次迭代后释放。 如果您想掌握您的发布管理，您将需要更多的信息，很少有分析员的答案。我强烈建议你这本书。     

如果您目前正在使用敏捷环境，那么您应该查看敏捷估算和规划书籍以获取一些建议。本书还包含有关发布计划的小章节。 应始终进行一些发布计划。发布是一个目标，通常涵盖3-12个月的开发=迭代集。它描述了项目成功的目标标准。它通常被描述为预期特征和某个日期的组合。在这种情况下，功能通常不是直接用户故事，而是史诗或整个主题，因为您几个月前都不知道所有用户故事。就个人而言，我认为发布是指当基于愿景的项目可以交付时。它需要来自愿景的高水平期望和约束，并将它们转换为某种估计。您还可以将项目划分为多个版本。 但请记住，三种力量也适用于敏捷。功能集，发布日期和资源之间存在直接关系（+有时也提到第四个力：质量）。推动其中一种力量总是会推动其他力量。它通常被建模为等边三角形（或正方形）。 计划发布有不同的方法。书中提到了一个。它基于用户故事估计，迭代长度选择和速度估计，但我对这种方法有点怀疑，因为你没有整个版本的简单用户故事，估计史诗和主题是不准确的。另一方面，高级功能定义正是三种力量所需要的。如果您没有足够的时间，您将只实现所有主题的基本功能。如果您有更多时间，您将实施更多高级功能。这是产品所有者在将史诗和主题划分为小用户故事时正确设置业务优先级的任务。 敏捷中最重要的部分是你很快就会知道。每次迭代后，您将更好地了解速度，并且还将重新估计一些计划的用户故事。出于这个原因，我认为应该在几次迭代后计划真实的估计（准确）和发布日期。正如我被告知不应该估计一项培训工作，应该努力衡量。如果有人抱怨它会向他展示瀑布，并问他什么时候会得到相对准确的估计？提示：在完成分析之前，应该在项目的30％之后说出来。 使用敏捷/ scrum以及项目需要多长时间，您希望实现哪种类型的项目也很重要。有些项目严格预算或日期驱动，其他项目可能更多的功能驱动。这可能会影响您的发布计划。对于简短的项目，您通常会有一些小的用户故事，您可以在开始时提供更准确的估算。     

这是一个非常有问题的问题，并且取决于您的公司。我首先要问，为什么你使用3个环境和持续集成（你的理由很重要）？你在进行自动化测试吗？你的代码分支是如何设置的？您是否发布了某些功能，或只是常规维护修复？ 回答这些问题可以让您了解为什么需要发布，以及如何进行发布。 例如，如果您只有一个用于集成和执行自动化测试的暂存环境，那么就不能拥有一个单独的代码分支，其中连续集成测试运行就足够了？ 如果升级是为了进行某种用户接受，您的公司是否有专门的测试团队，或者他们是敏捷团队的成员？ 正如您所说，如果代码始终是集成和测试的，那么为什么您需要时间表并从环境转移到环境，除非您不确定功能的实际“完成”条件？通过这个，我的意思是，你并不确定该功能是否正确编码，但是你担心它会引入其他错误吗？它会与已经生产的代码很好地集成吗？解决问题根源的问题。不要只是这样做，因为你认为你应该有X环境或测试应该在另一组。也许这些问题的解决方案可能是相应地调整“完成”的定义。 正如您所看到的，有许多因素会使您的组织与众不同。没有一种正确的方法可以回答这个问题，只是你愿意接受的权衡。 我发现，在不同层次上工作的人员团队的多个环境往往会产生反敏捷和适得其反的效果。最好的办法是分析您的问题，并尝试找到解决问题的方法（例如扩展“完成”的定义，或者拆分各种组织并将它们放在团队中，尽可能多地消除环境并简化过程等）。这在您的组织中可能是不可能的，因此您可能不得不忍受权衡。