PO和SM在Daily期间是否共享相关信息?
在这里大声地思考。我想知道敏捷社区对这个问题是怎么想的。亚博一百送一百如果阅读Scrum指南，就会发现每个事件都是一个检验和调整整个团队的机会。所有人都希望有一个;每日。只有一部分Scrum团队成员参与了这个会议;开发人员。是的，如果PO或SM同时也是开发者，他们也会参与其中，但只是作为开发者，而不是SM或PO。重点放在检查和调整计划以达到冲刺目标。但是PO和SM在冲刺阶段也有目标。 For example, the PO does PBL refinement. Sometimes the PO needs input from Developers for this. When the SM is working on solving an impediment, something that prevent the Developers from reaching the Sprint Goal, it could help to share what the SM is doing to solve it. During the Daily the PO could ask for help so the Developers can keep in mind who is going to help the PO. That does have influence on the plan for that day. Also not having solved the impediment could influence reaching the Sprint Goal and should be taking into account while creating the plan for reaching that goal.
你认为让PO和SM在Daily期间分享影响开发人员计划的信息是个好主意，还是应该在Daily之外进行交流，这样Daily就只针对开发人员了?
明确地说，Scrum指南并没有阻止产品负责人或Scrum管理员出席每日Scrum。由于“开发人员可以选择他们想要的任何结构和技术”，他们可以选择一个结构，其中包括产品负责人和Scrum管理员作为部分或全部日常Scrum的积极参与者。Scrum Master指导团队并确保所有事件“发生，并且是积极的、富有成效的，并在时间范围内进行”的服务也可能导致Scrum Master观察或促进每日Scrum。
就我个人而言，我的运气最好是产品负责人参加每日Scrum，最好是每天都参加。这让他们有机会确切地看到开发人员已经做了什么和将要做什么，这可以帮助产品负责人准备在他们完成时查看增量。换句话说，产品负责人可以根据他们在每日Scrum中的所见所闻来计划他们的一天。Scrum Master还可以获得有关障碍的第一手信息，团队不需要在后面寻找它们来让它们参与。仅仅是活在当下和观察，就有很长的路要走。
除了观察，产品负责人还可以让团队知道正在发生的事情，这可以帮助团队更好地计划他们的一天。这可以是任何信息，从产品负责人对与改进或当前Sprint工作相关的问题的可用性信息，到Sprint评审之前涉众方面的变更信息，这样就没有人会被蒙住了。
每日Scrum的目的包括改善沟通，促进快速决策，以及消除其他会议。在整个Scrum团队(包括产品负责人和Scrum Master)在场的情况下，这三件事都要容易得多。
不过，也有一些潜在的障碍。在一个可伸缩的环境中，多个团队致力于一个产品，产品负责人和Scrum Master可以为多个团队服务。如果团队选择在同一时间举行每日scrum，他们就不能同时出现在多个地方。考虑更多人的日程安排也会使日程安排变得更加困难，并导致团队在开发人员不太方便的时间进行每日Scrum。不过，适当的指导水平可能有助于缓解这些问题。
我绝对鼓励团队找到方法，让产品负责人和Scrum管理员定期参加每日Scrum，但要确保开发人员拥有会议的结构，他们的需求是第一位的。
一个好的每日Scrum就是从忙碌的一天中抽出15分钟与SM、PO和其他人合作，让那些开发增量的人站在热闹之外说:
“在哪里我们现在我们在冲刺目标的进程中?明天这个时候我们希望在哪里?”
对其他人来说，这是很有吸引力的，因为在15分钟的时间里加入是很容易的。剩下的时间，你可以呆在自己的泡泡里，这意味着你日常工作的变化更少。把协作挤进15分钟，你就有了每天的Scrum。
感谢您的回复和见解。它给人以思考的食粮。
我告诉我的学生，每天的scrum是朝着冲刺目标前进的微观计划和协调会议。SM和PM不一定要参加，但在实践中，他们的出席通常是有帮助的。不过，我在这个会议上看到过过于自信的短信和经理，把它变成了一个状态会议。
例如，PO执行PBL细化。
我不同意这种说法。产品负责人不做产品待办事项列表细化。Scrum团队对产品待办事项列表进行细化。我这么说是因为这是开发人员的工作，所以他们最好将项目细化为可操作的单元。Scrum指南指出，细化是一个持续的过程，因此整个Scrum团队应该有一个共同的理解，即每个人都将在不同的时间贡献时间。
你说的对，Daily Scrum是为开发人员准备的。它专门用于协调他们与实现Sprint目标相关的日常活动。正如其他人所说，他们可以确定最有效的方法。我的观点和指导是，如果产品负责人或Scrum Master有与Sprint目标相关的活动，那么他们应该参与其中。Scrum指南也指出了这一点。
但是PO和SM在冲刺阶段也有目标。
是的，他们可能有目标，但这些目标与Sprint目标无关，因为这个目标直接与Sprint Backlog相关，并且是对它的承诺。根据我的经验，产品负责人对每日Scrum的唯一有价值的贡献是提供信息，帮助澄清待办事项项的意图，而这并不是每天都会发生的事情。产品负责人能从每日Scrum的讨论中获益吗?这是可能的，但并非总是如此，因为谈话可能是深入的技术，并不是所有的产品负责人都能理解。Scrum Master能从倾听对话中获益吗?当然，但他们的好处是看到开发人员如何自我组织来解决问题并完成工作。这有助于Scrum Master履行对Scrum团队的职责。
你认为让PO和SM在Daily期间分享影响开发人员计划的信息是个好主意，还是应该在Daily之外进行交流，这样Daily就只针对开发人员了?
我的观点是，这种信息应该在知道后立即分享，而不是等到预定的时间才这样做。所有公司都有沟通的方式。我不知道哪个公司没有电子邮件。即时消息和视频会议也很好用。因此，即使团队不在办公环境中，也有提供信息的方法。因为开发人员可能会选择立即进行调整，所以应该在知道它后立即分享它。每日Scrum是改善和增加信息透明度的一种方法。但是，信息的共享不应该局限于日历上安排的时间。
谢谢你的建议。在我看来，完善PBL不仅是澄清US，而且还改变了顺序，增加或减少了PBL中的US。是的，PO不是唯一这样做的人，但负责PBL。所以我相信不仅仅是开发人员在进行完善。
我同意PO和SM的目标不是Sprint目标的一部分，但是它们可以影响SG的实现。此外，从透明度的角度来看，他们的目标应该对每个人都清楚。
我理解你的观点，在得知信息后立即分享。我同意。但分享这些信息作为提醒，或者如果你注意到开发人员在日常工作中没有考虑到这些信息，也无妨。另外，这也取决于球队的成熟度。有时开发人员需要一些强有力的问题来让他们在日常工作中回到正轨。
@Chuck;是的，状态会议是你想要阻止的事情。当我注意到它变成了一个，那是一个很好的时刻，从字面上后退几步，解释每日的目的，并观察发生了什么。
我认为你的回答更符合Scrum 2020指南，但另一个问题是，如果开发团队没有选择包括SM或PO在内的结构，并且SM感到难以实现Sprint目标，那么SM是否可以要求开发团队在日常Scrum中邀请PO ?
在日常的scrum中，SM是否可以要求it开发团队邀请PO ?
在我看来，Scrum Master应该可以自由地询问、建议和推荐任何数量的旨在使Scrum团队受益的实践，但不应该规定Scrum指南之外的任何东西。
关于Daily Scrum，我必须归功于伊恩•米切尔他的文章帮助我理清了这个话题的思路。
我们正在讨论的是整个工作日中的15分钟，我们专门分配给开发团队来回顾他们朝着Sprint目标的进展，并为接下来的24小时制定行动方针。
如果其他话题或交流很重要，我们可以为这些目的设立单独的会议，但我们不应该把这15分钟指定为团队每日会面和协作的接触点。
我认为你的回答更符合Scrum 2020指南，但另一个问题是，如果开发团队没有选择包括SM或PO在内的结构，并且SM感到难以实现Sprint目标，那么SM是否可以要求开发团队在日常Scrum中邀请PO ?
这与Scrum Master是否觉得团队在实现Sprint目标方面有困难无关。对于给定的Sprint，团队是否实现了Sprint目标，以及团队实现或未能实现Sprint目标的频率应该是非常清楚的。Sprint评审是团队与关键涉众讨论Sprint目标和产品目标进展的机会。
如果团队未能实现他们的Sprint目标，我希望团队使用Sprint回顾来理解原因。我还希望Scrum Master能够推动这个活动，并为团队提供指导和指导，但是如果Scrum Master要求开发人员采取特定的行动，那就越界了。然而，在开发人员和/或产品负责人没有想法的情况下，这确实是一个模糊的界限，可能会要求Scrum Master提出可能的改进建议。邀请谁参加每日Scrum将由开发人员决定。