Scrum Master 如何“管理”失控的产品负责人？ [关闭]答案

【问题标题】：How does a Scrum Master "manage" an out of control Product Owner? [closed]Scrum Master 如何“管理”失控的产品负责人？ [关闭]
【发布时间】：2008-11-20 23:09:23
【问题描述】：

我是 Scrum 新手，虽然我了解 Sprint 背后的团队概念，但我认为团队仍然需要一名监护人，以尽量减少不熟悉软件开发的产品负责人的干扰。你有哪些成功经历，你经历过哪些恐怖故事？

更新：

我正在寻找实现业务流程的编码与为客户创建适当架构之间的平衡。如果产品负责人来自业务部门，则必须就应该在数据模型上花费多少时间等提供指导。

定义：

我所说的“失控”产品负责人通常是指业务部门中的某个人，他们积极设定时间框架，但没有真正的技术能力来创建该估算。通常，此人会说：“我需要在下周与运营委员会的下一次会议之前获得这些屏幕，因此首先优先考虑这些工作产品。我们将在与运营部交谈后处理数据库。”

每个人的答案都很好。感谢您的宝贵意见。

【问题讨论】：

“来自产品负责人的干扰”？当然，如果他们拥有产品，他们的工作就是干预以确保开发人员不会误入歧途？
对结果的所有权与对活动的控制？
产品所有者可能正在干扰软件开发活动。例如，“你为什么这么频繁地向 svn 提交代码！难道你不能在第一时间就得到正确的代码吗？”
我投票结束这个问题，因为它不是一个编程问题。

标签： project-management scrum methodology

【解决方案1】：

Scrum 中明确定义了职责 - 产品负责人定义待办事项并确定它们的优先级，开发人员承诺他们可以在 Sprint 中完成多少工作。

因此，产品负责人根本无权设定估算值。当然，他仍然可以说他在特定的时间点需要某些东西——这很容易发生。但仍是开发人员会说它是否可以完成。如果不能，他们必须共同研究如何更改范围或采取其他任何措施，以尽可能最好地满足 PO 的需求。

现在，在这种情况下，SM 应该如何行动，这在很大程度上取决于具体情况。不过，我宁愿看到他促进 PO 和团队之间的良好关系和沟通文化，也不愿让他保护团队免受 PO 的影响。

【讨论】：

【解决方案2】：

“必须有关于应该在数据模型上花费多少时间等的指导。”

没错。这就是优先级的全部意义所在。你定义工作，你优先考虑。您按照优先级工作。

什么会失控？

在完成任何工作之前重新定义工作？
在工作完成之前重新定义优先级？

解决方法是一样的。将工作分解成更小的部分，以便在有机会做出改变之前完成一些事情。

如果您的冲刺时间很短（2 周），就不可能失控。如果您进行稍微实用的 4 周冲刺，那么您遇到麻烦的可能性很小。

【讨论】：

【解决方案3】：

产品负责人应该保护您免受模棱两可或多变的客户要求的影响。

产品负责人不得给出估算值。

【讨论】：

+1 - 我曾在业主来自业务分析师或项目管理背景的商店工作，但仍然不相信开发人员的估计！别管他们，他们会回来的。

【解决方案4】：

我不认为这是“失控”的问题。

“在下一个之前我需要这些屏幕与运营委员会会面下周，所以优先考虑这些工作产品第一。我们将解决在我们与 Operations 交谈后创建数据库。”

这句话本身并没有什么错误本身。如果您的应用程序被正确抽象，那么您的数据库无论如何都是独立的。 UI 的主要问题首先是更多的心理问题：非开发人员会认为如果他们看到屏幕并在事情“慢下来”时发疯，他们就会认为大部分工作已经完成。但是，我认为您的真正问题可能是：

您标记为产品负责人的人没有拥有产品，因此没有承担足够的责任。

产品是整体的东西，而不仅仅是“功能需求”（借用术语）。您的 SM 需要坐下来，并坚持 PO 不需要试图推开了解需要完成的幕后工作的范围。一旦您的 PO 开始着眼于整个范围，那么他们实际上可以成为您在更广泛的利益相关者社区中的代表。

最终，您的 SM 负责执行流程。他们应该这样做。

【讨论】：

【解决方案5】：

我在两家不同的商店使用过敏捷，两次都运行良好。我看不出任何失控的东西会如何破坏系统。在 sprint 之前，你计划好你将要做的所有任务，并猜测它们需要多长时间（总是四舍五入）。然后，您可以大致计算出在您的 sprint 期间可以完成多少工作。

大多数商店使用 4 周的冲刺，每天 6.5 小时的工作时间。设置 sprint 后，您不会引入新任务，只有潜入 sprint 的计划外工作会修复您正在添加的功能中的错误，当然这应该包含在您的估计时间中。

如果您想要更具体的答案，您需要定义“失控”产品所有者的含义。

【讨论】：

我猜我所说的失控是指一些没有技术背景但认为他们有能力设定时间框架的人。

【解决方案6】：

我有两件事要说。

您可能有某种类型的研发经理（不一定是 Scrum Master），也不是产品负责人）。

这个家伙可以而且应该（我认为）“保护”开发人员。当我们有这样一个人时，我们就处于这种情况，而且效果很好。例如，他帮助我们在积压工作中获得了非功能性的东西。

现在我们没有这个人了。我们的经理是 Scrum Master。他在保护我们方面也做得很好。虽然......这里的问题是通用 scrum master 没有官方权力，所以他不能说“你不会这么压他们”，但如果他看到团队需要帮助，他当然可以而且应该说。

团队本身和产品负责人也随着时间的推移而发展，因此他们开始更加关心彼此。产品负责人理解团队何时不承诺更多或说“我们现在需要一些时间来处理非功能性的东西”。

但话又说回来，如果有一个单独的研发经理，其主要职责是照顾开发人员，那当然很好......那么我认为它会更加平衡......

我们还有支持部门借用开发人员来完成支持任务。有时很难就该客户或该客户将要做什么或不做什么达成一致（因为支持需要这一切）。对于这种情况，研发经理 - 也是一个非常好的主意..

理想情况下，我喜欢完全精简的想法，这样开发人员就不需要经理或盾牌……但我不知道它是否以及如何运作……:)

【讨论】：

【解决方案7】：

我同意 S. Lott 的观点。短冲刺更好。简短的用户故事可以提供帮助。我们尝试将我们的用户故事限制在最多 2 到 4 天。

确保您的所有用户故事定义明确，而且业主与他们达成协议。
冲刺开始后，坚持无法添加新任务当前的 sprint，但它们可以是在下一个 sprint 中具有高优先级。更短的冲刺可以做到这一点更容易。
另外，为了删除强加人为的最后期限，你真的不应该送东西从当前 sprint 到下一个 sprint 的开始时间可能。

敏捷开发最难的部分是纪律。一旦你有一个纪律严明的团队和 scrum master，用户就会习惯它，事情就会变得更加顺利。我不确定您是否使用任何软件进行项目管理，但看看 Rally。在过去一年左右的时间里，他们取得了一些重大改进。

【讨论】：

【解决方案8】：

在迭代期间不应更改迭代（Scrum 中的 Sprint）范围。这就是为什么一次只计划一次迭代。正如 S. Lott 所指出的，迭代越短，产品负责人就能越早规划新事物。

Scrum Master 的角色是将团队与这种压力隔离开来，并向产品负责人说新请求必须等待下一次迭代。

现在产品负责人的角色是最大化团队生产的工作的价值，所以如果有一个新的最高优先级的项目，不能等待当前迭代结束，仍然可以替换项目有类似的估计和尚未开始。这应该是例外，而不是规则。

【讨论】：

【解决方案9】：

坚持明确定义的参与规则，然后您 (SM) 可以花时间领导您的团队。

【讨论】：

【解决方案10】：

敏捷团队由开发人员、业务分析师、测试人员、DBA、Scrum master 和产品负责人组成。所有人都作为一个基于功能的团队工作。

敏捷方法可帮助企业加快产品开发速度。产品所有者可以定义优先级并更改其优先级。实际上，它是一个 Scrum 团队，他们估计它包括（SME、开发人员、设计师、测试人员……每个人）。每个团队成员对产品和交付用户故事所需的工作都有不同的看法，一个 sprint 包括大和小的用户故事。如果 Scrum 团队觉得它不能在 sprint 内完成，那么它需要分成用户故事的一小部分，并根据开发它所涉及的堆栈跟踪进行估计。

即如果产品负责人（PO）希望特定的用户故事需要先完成，但如果该故事包含多个更改（即前端和后端，包括数据库）并且无法在一个 sprint 中完成，Scrum 团队可以遵循以下关键规则：

关键要素：

根据堆栈轨迹划分子用户故事
估计与此相关的每个用户故事
Scrum 主管应通知产品负责人有关时间表根据团队当前的团队速度完成此用户故事
产品负责人应该足够成熟，能够理解时间线，因为它无法在冲刺内完成。
如果Still PO优先级有问题，他/她可以咨询 Scrum 大师/教练。

一目了然，敏捷更多是为了帮助业务，但需要注意这一点它不会使 Scrum 团队超载。因为这是一个常规的过程迭代开发。

【讨论】：

死灵怎么了？
Necroing 本身不是问题，但在这种情况下，它会引起人们对现在偏离主题的旧线程的关注，确保它会被关闭。