我是Scrum的新手，虽然我了解Sprint背后的团队概念，但我想仍然需要为团队提供一名监护人，以尽量减少不熟悉软件开发的产品所有者的干扰。你有什么成功，你经历过什么恐怖故事？
更新
我正在寻找实现业务流程的编码与为客户端创建适当架构之间的平衡。如果产品所有者来自业务部门，则必须指导应在数据模型上花费多少时间等。
定义：
“失控”产品所有者通常是指业务部门中的一个人，他们积极地设定时间框架，而没有真正的技术能力来创建该估算。通常这个人会说：“我需要在下周与运营委员会的下一次会议之前进行这些筛选，因此首先要优先考虑这些工作产品。我们将在与运营部门交谈后处理数据库。”
很好地回答每个人。感谢您的良好投入。
答案 0 :(得分：5)
在Scrum中明确定义了职责 - 产品负责人定义了积压项目并对其进行了优先级排序，开发人员承诺他们可以在Sprint中做多少。
因此，产品负责人根本没有权限来设定估算值。当然，他仍然可以说他需要某个特定时间点的东西 - 这恰好发生了。但仍然是开发人员会说是否可以完成。如果不能，他们必须一起研究如何改变范围或其他任何可以做的事情，以尽可能地满足PO的需求。
现在，SM应该如何在不能顺利运行的情况下采取行动，这在很大程度上取决于具体情况。我宁愿看到他在PO和团队之间建立良好的关系和沟通文化，也不会让他屏蔽来自PO的团队。
答案 1 :(得分：3)
“必须指导应该花多少时间在数据模型等上”
右。这就是优先顺序的全部意义所在。您定义工作，优先考虑。你按照优先事项工作。
什么可能失控？
在完成任务之前重新定义工作？
在工作完成之前重新定义优先级？
解决方案是一样的。将工作分解成更小的部分，以便在有机会进行更改之前完成某些工作。
如果短跑（2周）短跑，则无法失控。如果你选择稍微更实际的4周冲刺，那么你很有可能遇到麻烦。
答案 2 :(得分：3)
产品所有者应该是保护您免受模糊或不同客户要求的产品所有者。
产品所有者不得提供估算值。
答案 3 :(得分：3)
我认为这不是一个“失控”的问题。
“我需要在下一次之前使用这些屏幕 与运营委员会会面 下周，优先考虑这些工作 产品第一。我们将解决这个问题 我们与运营部门谈话后的数据库。“
该声明本身没有任何内在错误。如果您的应用程序被正确抽象化，那么无论如何您的数据库都是独立的。 UI首先出现的主要问题是心理上的问题：非开发人员会认为，如果他们看到屏幕并且当事情“减速”时就会完成大部分工作。但是，这就是我认为你真正的问题所在：
您标记为产品负责人的人不拥有该产品，因此没有承担足够的责任。
产品是整个的东西，而不仅仅是“功能要求”（借用术语）。您的SM需要坐下来并坚持认为PO不需要试图推翻理解需要完成的幕后工作的范围。一旦您的PO开始查看整个范围，那么它们实际上可以成为您对更广泛的利益相关方社区的代表。
最终，您的SM是负责执行流程的人员。他们应该表现得像。
答案 4 :(得分：1)
我在两家不同的商店使用过Agile，两次都运行良好。我不知道失控是怎么会破坏系统的。在sprint之前，你计划你将要完成的所有任务并猜测他们将花多长时间（总是向上舍入）。然后你可以弄清楚你的冲刺期间可以做多少工作。
大多数商店使用4周冲刺，每天工作6.5小时。设置sprint后，你不会引入新的任务，只有进入sprint的计划外工作会修复你添加的功能中的错误，当然这应该包含在你的猜测时间内。
如果您想要更具体的答案，您需要定义“失控”产品所有者的含义。
答案 5 :(得分：1)
我有两件事要说。
您可能拥有某种R＆amp; D经理（不一定是Scrum master），而且不是产品所有者）。
这家伙可以而且应该（我认为）“保护”开发人员。 当我们有这样一个人时，我们处于这种情况，并且它运作良好。例如，他帮助我们在积压中获取非功能性的东西。
现在我们没有这个人。我们的经理是scrum master。而且他也很好地保护了我们。 虽然......这里的问题是通用的Scrum大师没有官方权力，所以他不能说“你不会这么强迫他们”，但他当然可以而且应该说，如果他看到teem需要帮助。 / p>
团队本身和产品所有者也随着时间的推移而发展，以便他们开始更多地关注彼此。产品负责人了解团队何时不承诺更多或说“我们现在需要一些时间来处理非功能性的东西”。
但是 - 然后 - 再次 - 当然，如果有一个独立的研发经理，其主要职责是照顾开发人员，那就太好了......那么我认为它会更平衡......
我们还有支持部门，他们借助开发人员来支持任务。有时很难同意为这个或那个客户做什么或不做什么（因为支持需要它）。 对于这种情况，R＆amp; D经理也是一个非常好的主意......
理想情况下，我喜欢完全精益求精的想法，以便开发人员不需要经理或盾牌......但我不知道它是否以及如何运作...... :)
答案 6 :(得分：1)
我同意S. Lott的观点。短冲刺更好。简短的用户故事可以提供帮助。我们尝试将用户故事限制在最多2到4天。
确保您的所有用户 故事定义明确 所有者与他们达成协议。
一旦sprint开始，坚持 无法添加新任务 目前的冲刺，但他们可以 在下一个冲刺中具有高优先级。 更短的冲刺使得这一点变得更多 更容易。
另外，为了删除 强加人为的最后期限， 你真的不应该送货 从目前的冲刺直到 下一个冲刺的开始时 可能的。
敏捷开发最难的部分是纪律。一旦你有一个训练有素的团队和scrum master，用户就会习惯它，事情会变得更顺畅。我不确定你是否使用任何软件进行项目管理，但请看看Rally。他们在过去一年左右的时间里取得了一些重大进步。
答案 7 :(得分：1)
迭代期间不应更改迭代（Scrum中的Sprint）范围。这就是为什么一次只计划一次迭代的原因。正如S. Lott指出的那样，迭代越短，产品负责人就能越早计划出新的事物。
Scrum Master的作用是将团队与此类压力隔离开来，并向产品负责人说新请求必须等待下一次迭代。
现在，产品所有者角色是最大化团队生成的工作价值，因此如果有一个新的最高优先级项目，它不能等待当前迭代的结束，仍然可以替换项目具有类似估计值和尚未启动。 这应该是例外，而不是规则。
答案 8 :(得分：1)
坚持明确定义的参与规则，然后您（SM）可以花时间领导您的团队。
答案 9 :(得分：0)
敏捷团队由开发人员，业务分析师，测试人员，DBA，Scrum管理员和产品负责人组成。所有人都在作为一个基于功能的团队工作。
敏捷方法可以帮助企业加快产品开发速度。产品所有者可以定义优先级并更改其优先级。实际上，它是一个Scrum团队，估计它包括（中小企业，开发人员，设计师，测试人员......每个人）。每个团队成员对产品和提供用户故事所需的工作提出了不同的观点，一个sprint包括大和小用户故事。如果Scrum团队认为它无法在sprint中完成，那么它需要分成用户故事的一小部分，并根据开发它所涉及的堆栈跟踪进行估算。
即。如果产品负责人（PO）希望首先完成特定用户故事，但如果该故事包含多个更改（即前端和后端包括数据库）并且无法在一个sprint中完成，则Scrum团队可以遵循以下关键规则：< / p>
关键要素：
如果Still PO有优先权问题，他/她可以咨询 Scrum Master / Coach。
一目了然，敏捷更多的是帮助企业，但需要注意这一点 它不会超过scrum团队。因为这是一个常规的过程 迭代开发。