在Scrum每日站立会议中进行与非签到相关的讨论是否可以接受？

我希望人们会给我一个潜在的明显问题。我曾在许多每天召开Scrum会议的组织中工作。一些组织确实严格只使用Scrum进行签入（“三个问题” –您昨天做了什么，您今天在做什么，您是否有任何阻止者？），而另一些组织则倾向于使用其他常规服务。公告或详细的技术讨论。

我已经听到过这样的争论，例如在本文中，允许像这样与非签到相关的讨论是一个错误-Scrum会议不应用于Scrum Master的一般公告，技术讨论等。

我从中看到的主要危害是会议的持续时间可能超过必要的时间（被迫参加与我无关的细节讨论很烦人）。

显然，与整个团队无关，不属于“三个问题”的讨论不应该成为直言不讳的一部分。但是，如果还有其他与整个小组相关的公告，无论如何都需要进行讨论，那么在那时（而不是在单独的会议或电子邮件中）进行讨论是否有害？

每日Scrum的目的是让开发团队查看过去的24小时，并更新他们接下来24小时的计划。

根据《 Scrum指南》，达到此目标并能在15分钟内完成的所有任务正是Daily Scrum的目的。如果您需要进行较长时间的对话，则只需不断记录一下它们是什么，然后在“每日Scrum”结束时，分成几个小组关注该主题。

Daily Scrum的目的不是要找出问题的解决方案。之后...

当然可以接受，但是首先要关注重要的事情。如果我们有时间留在15分钟，这是很常见的一个5人的开发团队正在蜂拥（因为他们在开发过程中同步更多的时候），我有额外的通信和或公告没有问题。只要我们将它们推迟到每日日报结束。

作为一名Scrum Master，我确保团队以某种方式回答了三个关键问题。

Daily Scrum是一项15分钟的有时间限制的活动，开发团队可以同步活动并为接下来的24小时制定计划。

有时需要简短的技术讨论来同步团队。作为Scrum Master，我确保我们适合15分钟的时间范围，并切断站立后的较长时间的讨论。

开发团队或团队成员通常在“每日Scrum”之后立即开会，进行详细讨论，或者调整或重新计划Sprint的其余工作。

从非Scrum和更敏捷的角度来看。专注于什么对团队有效，什么对团队无效。只要确保团队做出决定并尝试更改，便可以使他们更有效并生产更高质量的软件。

团队成员应牢记站立的要点，即彼此保持私密或在有限的圈子内可能需要更长的时间来解决问题。另一方面，避免重要且关系到整个团队但不符合Scrum袖珍书中规定的准则的问题并不是很敏捷。仅因为显然要节省时间的规则而安排单独的会议是愚蠢的。

发言者可能并不总是清楚自己的问题是什么。如果让他闲逛一会儿，就会使其他人清楚他正在挣扎或走上一条死路，毕竟您可能会有所收获。过于关注形式也会损害生产力，并使人们感到沮丧。

视文化而定，立场可能很严格，也可能包括社会问题。决不应该将其视为“僵尸混乱”的盲目经历。

人们强烈要求的是Scrum与过程之上的人的概念之间常常存在二分法。

如果有信息要传达，最终就是一个判断电话。如果可能引起大量讨论，最好将它移到另一个时间。如果只是像服务器停机之类的事情而很快，那么可以在那做完。当然，在这两种情况之间会有阴影，在这种情况下，Scrum管理员应仅建议在15分钟（或任何其他时间）后将其离线。

无论哪种方式，我都倾向于在常规的站立过程完成后将其放在最后。

您问，“有害吗？” 但是其他答案大多针对“会议的目的吗？”，我认为这是不同的问题。当您将其他议程项目偷偷带到会议上时，这确实是有害的，尤其是当它变得习惯时。站起来每天花费大量时间，通常是在一天中最有生产力的时间，即人们精力充沛的早晨。如果人们不能指望站立起来足够长且不再与他们完全相关的站立，就可以从他们身上消耗掉这种能量。

人们将开始迟到，因为他们从事的是“更具生产力”的事情。他们甚至根本不会出现。其他人会迟到或根本不出现，因为“所有人”都迟到或根本不出现。这些问题会相互加剧，并且站立式站立架对于其原始目的不再有用。这听起来很极端，但是我已经看到了它的发生。如果执行此操作，请特别注意其方向。

我参加过的大多数团队有时会在站立会议后立即举行设计会议，如果谨慎使用也没关系，但是老实说，如果我告诉站立会议的队友我很快就会被阻塞，需要设计输入，我会得到更好的结果。我打算在那天下午安排一次会议。这也使他们有时间思考问题，午饭后人们陷入低迷，希望改变步伐。而且，这样一来，就不会让人们竞争成为第一个在站立后进行“小型会议”的人，以便他们离开。

当然，我绝不提倡盲目做某事或不做某事，只是因为互联网上某个随机的人（甚至是我）告诉过你。 在流程和工具上的个人和互动。 如果您确实决定在站立会议上介绍一些其他议程项目，我建议在以后的回顾中特别提出来，看看团队是否发现它具有破坏性，并根据需要进行调整。最终，每个团队的舒适度都不同，并且对合适与否的看法也不同。

更新：我应该清楚：15分钟是您应该进行任何站立的最大时间-遵循以下规则的有效站立通常最多不会超过5分钟，并且如果您可以将该时间进一步缩短甚至更好。再说一次，您认为最相关的大多数讨论都可以在简单的每日签到流程之外轻松地在团队成员之间进行讨论，而站立应该是最纯粹的形式。

经验法则我在与朋友的项目中坚持并深入研究，并在专业环境中磨练：

• 昨天

您昨天所做的工作分别推进了该项目，并且在相关的情况下影响了其他人。

• 今天

如上所述，但今天

• 阻滞剂

不管多么琐碎（可能有人可以过来检查您的代码或进行健全性检查），任何可能导致该问题的内容都会引起警报

其他任何事情都会使人分心。这可能意味着主题“可能”似乎与项目进度实际上无关。这很苛刻，但是对于XP来说非常有效。

站立会议的目的是进行有效的沟通。将目标设定为目标，而不是盲目遵循。既然您发布了这个问题，那么您就走对了。

您所有的担忧都是有效的。尽管我们可以尝试预期是否会造成任何问题，但我只是建议您尝试一下来回答您的问题。

避免以下情况：

1. 会议时间过长。
2. 太多的人喜欢在其他地方发布公告。在预定的会议中这样做很诱人，但不要滥用它。大多数人讨厌会议。
3. 信息并不适用于所有人。偶尔会有一些例外。
4. 每次会议都是出于习惯而不是需要来发布公告。要专业。

做出有教养和明智的决定，不要掩盖过度申请或严格遵循规则。

大多数敏捷模型为刚进入敏捷过程的团队提供了一个很好的起点结构。这并不意味着它们不能进行更改以满足您的需求。如果这些公告不能改善沟通，请不要这样做。看起来很简单，但是...