有关何时进行产品积压整理的提示

最新推荐文章于 2024-10-08 12:37:10 发布

danpu1174

最新推荐文章于 2024-10-08 12:37:10 发布

阅读量165

点赞数

文章标签： python 人工智能 java 大数据机器学习

选项1：在Sprint审查会议中

您的第一个选择是在sprint审查会议中处理产品积压。假设开发人员开发了“完成的”产品，并且有合适的人员在场，则可以使用与会者的反馈来做出相关的产品决策并更新积压的产品，如《 Scrum指南》所建议和下图所示。

这种方法可确保在下一个sprint开始之前更新积压。这使您可以立即采取任何新的见解，从而降低将产品带入错误方向的风险。此外，积压工作正在协同进行。这会导致参加sprint审查会议的人员大力支持。

但是，只有当与会者能够提供相关反馈，愿意合作并且可以Swift同意必要的积压变更时，它才起作用。此外，反馈不得要求进一步分析或引起更大的积压更改。如果您的产品积压中存在大量不确定性和更改，例如，如果您使用新产品或延长产品的使用寿命，则不要使用此选项。

选项2：

第二种选择是在下一次sprint计划会议之前召开单独的产品积压工作坊。研讨会应包括您作为产品所有者，开发团队和ScrumMaster。协同分析数据并处理积压，可减轻由于认知偏见而得出错误结论的风险；它利用了团队的创造力和知识，增加了理解和支持，并带来了更好的要求。

如上图所示，我更愿意在下一个冲刺开始时召开研讨会。这违反了Scrum规则，即冲刺计划会议必须是每个冲刺中的第一个事件。但是，它使您可以在后续的sprint中对反馈做出响应，而不必急于或放弃sprint回顾，也不必在晚上或周末工作。此外，它还提供了将数据收集与分析分离的好处：它使您可以在没有提供反馈的人员在场的情况下查看反馈。它还使您有更多时间评估反馈，得出正确的见解，做出正确的产品决策并相应地更改产品积压。这使得处理困难的反馈和请求以及进行更大的产品待办事项更改变得更加容易。

请注意，该方法仍然假设您可以在sprint审查会议中收集相关反馈，例如，通过执行产品演示，可用性测试或解决方案采访。如果您决定将产品增量发布给（选定的）用户，则不太可能为您工作，因为根据我的经验，收集相关数据通常需要几天的时间。请看下一个选项。

选项3：

如果您通过向（选定的）用户发布软件来验证您的产品决策，那么选项三可能适合您。建议您在进行下一个sprint计划后，召开由开发团队和ScrumMaster组成的产品积压研讨会，如下图所示。该方法假定您需要几天的时间来收集相关的用户数据，然后才能对其进行分析并进行适当的积压更改。它还假设您不必等待数据到达就可以确定下一个冲刺目标。相反，您可以在收集数据时继续进行下一个冲刺。

尽管选项三使您可以定量地验证产品，但它也有一个缺点：由于对sprint进行了保护，因此您可以对积压更改做出响应的最早时间是sprint + 2。因此，建议从选项一和第二开始，一旦解决了积压中的关键风险，则使用选项三。此外，与sprint n相比，您应该重点关注sprint n + 1中的其他功能，以避免基于错误决策的危险。

选项4：连续

如果您不需要等到sprint结束就可以发布新功能或改进的功能，那么适合您的选项四是：不断收集数据，对其进行分析并相应地更改积压。您可能希望每天早晨留出30分钟的时间查看最新数据并从中得出正确的结论，最好在开发团队或其某些成员的帮助下进行。

请注意，选项4假设您要么对产品进行少量的增量改进，要么运行多个重叠的实验来测试有关新功能或改进功能的想法，例如，通过发布功能假货或MVF 。

严格来说， Scrum不太适合支持这种方法。该模型假定跨职能的开发团队必须共同工作数周才能实现共享的sprint目标并交付产品增量。冲刺旨在运行一个实验或实现相关的产品功能。它不是特别适合执行多个测试并连续发布较小的增强功能和错误修复。因此，当我在我的文章《 Scrum适合您的产品吗？》中更详细地讨论时，您可能会考虑从Scrum转换为基于看板的过程。。