发布计划_发布计划建议

最新推荐文章于 2023-12-30 16:15:00 发布

danpu1174

最新推荐文章于 2023-12-30 16:15:00 发布

阅读量689

点赞数

文章标签：项目管理 java 大数据人工智能 python

原文链接：https://www.javacodegeeks.com/2020/01/release-planning-advice.html

版权

发布计划对于确保产品发展方向和战略至关重要，但实践中可能存在不足。本文提出了五个建议：明确目标，使用产品路线图，优先考虑成功因素，正确估算，以及协作跟踪进度。通过设置可衡量的目标，使用路线图规划多个版本，考虑不确定性和质量，采用粗略估算，以及使用发布燃尽图，可以帮助产品团队和利益相关者保持一致，提高发布成功率。

摘要由CSDN通过智能技术生成

发布计划

发布计划是与敏捷团队合作的产品人员的一项重要任务：它确保产品朝着正确的方向发展，并且将战略和策略联系在一起。尽管很重要，但根据我的经验，发布计划并非总是有效地实践。本文分享了我的建议，以帮助您反思发布计划的实践并加以改进。

发布计划需要什么以及为什么要这样做

尽管发布和发布计划是通用术语，但我发现不同的人赋予它们不同的含义。我认为释放的版本的产品，例如，Mac OS X的卡塔利娜和Windows 10发布有两种形式：主要版本，像iOS的13和次要版本，例如iOS 13.3。

发布计划是确定一个或多个主要发布的预期结果并最大程度地实现该目标的过程。这涉及以下内容：

建立明确，具体和可衡量的目标。我将这些目标称为产品或发布目标，并将其捕获到产品路线图中。
确定要完成的工作。通常，开发团队需要提供粗略的高层估计。
了解日期和预算限制：是否有必须满足的严格期限，或者预算是固定的？
监视从冲刺到冲刺的进度，并根据需要进行调整。在Scrum中，发布计划是迭代执行的，通常在冲刺结束时就可以清楚地知道进度了。

发布计划使组织能够做出明智的投资决策；它设定期望，使利益相关者和开发团队保持一致；它使产品人员可以指导开发团队的工作。

因此，作为产品负责人符合您的最大利益，以确保有效地执行发布计划。这要求您积极参与工作，而不是将其委派给开发团队或Scrum Master 。

使用产品路线图计划多个版本

发布计划在两个级别上进行：跨多个主要版本以及单个发布内。前者可以通过产品路线图很好地完成。我更喜欢使用面向目标的路线图，如下图所示的我的GO产品路线图，该路线图阐明了未来12个月每个主要版本的预期收益或成果。示例目标包括获取新用户，增加转换率，降低成本以及消除技术债务以使产品过时。

产品路线图上的目标应该讲述有关产品可能开发的令人信服的故事。正如我在“ 产品路线图优先级 ”一文中更详细地解释的那样，他们应该描述您要走的旅程，以便为用户和企业创造价值。这样的路线图提供了目标的连续性，并确保各个发行版相互依存，从而以系统的方式开发和增强产品。此外，路线图目标通过将产品的内容限制为满足下一个发行目标所必需的项目，来帮助您集中产品积压。

但不要忘记定期检查产品路线图 -根据经验至少每三个月检查一次。当您了解有关开发团队取得进步的能力并更好地了解如何最好地满足用户和业务需求的能力时，您将需要更新路线图。这样可以确保计划保持可行，并为利益相关者和开发团队提供必要的指导。

优先考虑发布的成功因素

在理想的情况下，开发团队将按时，按预算交付产品路线图中的所有版本。但是实际上，确实发生了不可预见的事情。例如，开发进度可能没有预期的快，或者其中一项技术可能无法按预期工作。

为了最大程度地获得成功的机会，我建议您为产品路线图上捕获的发布确定目标，日期和预算的优先级。一种方法是确定未（完全）达到目标，错过所需的发布日期以及超出预算的影响。然后修复最重要的因素-如果您不遵守该因素将造成最大的损害，从而对产品的成功产生最大的影响。尝试保护第二重要的因素，它会造成第二大损害。最后，第三个要灵活一些，这对主要版本的成功影响最小。

您可能已经注意到，我没有提到质量。这是有原因的：质量应该是固定的，而不是妥协。否则，即使不是没有可能，响应用户的反馈意见和不断变化的市场状况并Swift调整产品也是很难的。

采用正确的估算方法

估算产品路线图上的发布成本有助于获取必要的预算，或者，如果预算是固定的，则了解路线图是否切合实际且可操作（开发团队是否可以实际实施）。粗略的高水平估算通常足以满足此目标。

要得出估算值，请利用您开发相似产品或相同产品以前版本的经验；考虑您的公司中是否有足够的具有合适专业知识的人，或者您是否必须雇用或签约人。这应该给您指示所需的人工成本。然后添加设施，基础设施，材料，许可证和其他相关项目的成本。与开发团队一起进行此练习。

如果您认为得出的估计值过于模糊，请考虑以下选择：将路线图功能预先分解为史诗和用户故事，将导致冗长而详细的产品积压，难以调整和维护。另外，根据我的经验，此过程可能需要数天，有时甚至是数周。尽管您将获得更详细的估计，但在此阶段它们并不准确。

一旦确定了必要的预算并确保路线图上的发布是切合实际的，请执行下一步并储备产品积压。正如我在“ 产品路线图和产品待办事项列表 ”一文中所解释的那样，我希望将待办事项集中在即将发布的版本和下一个路线图目标上。要遵循这种方法，请从属于适当目标的功能中衍生出史诗。然后，探索该版本必须提供哪些其他功能，并将它们作为史诗添加到产品积压中。最后，确定项目的优先级并优化高优先级的项目。这将导致简洁，紧凑的待办事项清单，相对容易进行调整，并提供足够的现成的，高优先级的项目。不要忘记让开发团队参与此练习。

另外，请团队估算产品待办事项。如麦克·科恩（Mike Cohn）的著作《 敏捷估算与规划 》（ Agile Estimating and Planning）中所述，这可以通过使用故事点和规划扑克来完成。

使用发布燃尽图跟踪进度

发布燃尽图是一个简单但功能强大的工具，可以跟踪和预测发布进度。尽管它很有用，但经验告诉我，许多Scrum产品所有者并不使用燃尽功能。但是创建图表很简单。首先，要求开发团队估算应作为发布一部分的产品待办事项的总数。粗略的，高层次的估计就足够了。然后绘制一个坐标系统，该系统考虑时间，冲刺和产品积压中的工作量（可能表示为故事点）。

第一个数据点是在进行任何开发之前的估计工作量。要到达下一个数据点，请在第一个冲刺结束时确定产品积压工作中的剩余工作量。然后通过两个点画一条线。这条线称为燃尽线。它显示消耗产品积压工作量的速率。它受两个因素的影响：产品积压和速度的变化，这是开发团队取得进步的能力。通过将燃尽线延伸到水平轴，可以预测何时可能完成开发工作，或者是否可能达到发布目标并在特定日期交付所有相关产品待办事项。

上面的释放燃尽图显示两行。实线是实际消耗。它记录了迄今为止的进度和剩余的工作量。虚线是根据迄今为止的燃尽预测的进度。请注意，第二个Sprint中的燃尽是平坦的。这可能是由于将新项目添加到产品待办事项列表或开发团队修改了估算值引起的。

要获得尽可能准确的预测，请尝试以下三个技巧：

将预测基于趋势而非单个冲刺。这通常需要您运行两到三个冲刺，然后才能创建发布的第一个预测。
考虑过去冲刺的燃尽对其余冲刺的代表性。在上面显示的示例中，第二个sprint具有平坦的燃尽状态。这可能是由于基于第一次sprint审查会议或开发团队重新估计项目而将更多项目添加到产品积压中。为了获得正确的预测，值得考虑再次发生扁平燃烧的可能性有多大，您应该在多大程度上考虑到这一点。如果您确定极不可能再次发生，则在上面的示例图中，您的预测可能会更陡峭。
确保按风险确定产品待办事项的优先级，尤其是在早期冲刺中。这使得积压在前几个冲刺中发生变化，然后开始稳定的可能性更高。这使得对开发工作的其余部分进行预测变得更加容易，并且可以使预测更加准确。

如果预测表明您偏离轨道，燃尽速度比预期的慢，请确定原因。例如，开发团队可能缺少一些关键技能，团队可能太小，技术可能无法按预期工作，您可能过于乐观，或者最初的估计可能是错误的。确定主要原因后，请决定如何应对。上面建议的目标，时间和成本的优先次序将帮助您实现这一目标。

请注意，如果您必须推迟发布日期或对发布目标进行较大更改，则可能会对产品路线图产生影响，并要求您对其进行调整。