为什么以及为什么开发人员可能不喜欢“每日混乱”？[关闭]

举行每日Scrum有很多优点，例如：

1. 团队互相协调
2. 每个人都知道完成了多少任务
3. 燃尽图变得越来越完整
4. 任务板已更新
5. 它不会持续那么长时间，十五分钟不会杀死任何人

但是，最近（在实施和使用Scrum的6个月之后），我觉得我们的开发人员已经不再每天都喜欢Scrum。人们只是更新任务板，而没有解释足够，这似乎使他们感到无聊。我看到，无论出于什么原因，如果我们不坚持，他们就会变得特别高兴。

我只是不知道这可能是什么问题。有什么理由提到“每日混乱”可能给团队带来的不利吗？开发人员厌倦了日常混乱的原因可能是什么？

我曾与几位雇主一起参加过“ SCRUM”团队。在我看来，经理们将“每日Scrum会议”作为SCRUM的要点，并将其设定为目标，而不是按其目的：实现更有效的开发周期。

15分钟的会议很快变成45分钟的会议，更新没有效果，因为人们会忙着打着哈欠，想着“我们什么时候可以去了”，而不是听别人的话，这也会破坏人们的常规（例如，我是猫头鹰，每天早上9点开始参加这个愚蠢的会议，这是我辞职的充分理由。

当管理者提出一些想法，如果正确应用可能会很好，然后将其推向极致-他们得到的结果与预期的结果完全相反。我个人认为，我参加的会议越多-我所做的工作就越少。我的日历中每周有2次例行会议，通常会跳过其中之一。会议是给经理的，而让开发人员去做他们的工作。

我敢肯定会有很多SCRUM爱好者说“但这太好了”-好吧，保存，我已经听到了。

如果我觉得其中几乎没有价值，那么我每天都会感到无聊和无用。有一些事情可以减少日常站立的效用。

• 共享的信息绝不会以任何方式影响我。
• 缺乏团队所有权，每个人总是在自己的项目上工作。
• 站立时缺乏团队沟通。
• 缺乏可见或交流的进度。
• 缺乏信息共享。

这些只是我的头上，但总是有更多可能的原因。

也许您应该只问开发人员为什么他们似乎不感兴趣？如果您想要更多/更好的沟通，它应该从您开始。

每日SCRUM会议遇到的一些问题：

• 那些持续时间太长。您不希望任何经理人每天都在工作，因为它们是此类问题的根本原因。看看他们通常会怎样坐在椅子上（是的，不得不站起来是为了诱使人们禁食）
• 不必听到某人（或2或3个开发人员）详细描述他所遇到的任何孤立问题，而不必决定稍后再安排一次真正的会议来与有关人员讨论
• 愚蠢的小时。那些会议不一定要在早上：您不是在谈论昨天的工作，而是在决定今天的工作；您要说的是您在上一天到下一天之间所做的事情，并确定下一天之前要做什么。
• 开发人员缺乏该应用的所有权。如果未将开发人员视为代码猴子，则SCRUM起作用。流程出错的第一个迹象是，当开发人员没有评估需要花费多少时间才能完成某项工作时。
• 又愚蠢的小时。如果团队的一部分已经开始从事某些工作，并且在日常工作发生时“处于区域内”，这将很麻烦。每天进行这些活动的好时机是什么时候都不应该工作（例如，午餐后或午餐前开始进行一些讨论之前）。

时间是许多人的杀手.。程序员喜欢迟到编码，睡到很晚，然后在早上高峰后进来。必须在固定的时间上班-对他们来说还为时过早。对于其他可能会更早进入并已经开始工作的人来说，为时已晚。

流量是另一个问题。具有某些功能的程序员将一直工作到深夜，回到家后重新充电并准备继续。不得不参加一个与大多数无关的问题的会议可能会分散他的注意力。

我的观察是，这些会议经常使经理看起来和感觉像他们实际上在做某事，而不是对团队和项目有用。

例如，分配了一个团队对不同项目进行一系列简短的错误修复。他们实际上不是团队合作，而是个人合作。但是，由于公司/部门政策强制执行，因此团队负责人/经理每天都会举行一次Scrum会议。完成的所有工作都是花15分钟以上的时间参加无用的会议，并在会议之前和之后花费15-30分钟的时间分散精力和缺乏生产力。

现在，我已经看到Scrum在一个期限紧迫的项目中做得很好，并且需要在从事不同工作的人员之间进行大量协调。在这种情况下，这是一个很棒的系统。但是，在“我们开会是因为我们是一家Scrum /敏捷商店，而这正是我们应该做的事情”的背景下，确实很糟糕。

确保没有人垄断会议。

如果有4个开发人员在5分钟内摆脱了困境，接下来的10分钟就用在团队负责人的身上，详细介绍了他所做的所有令人惊奇的，令人敬畏的新开发，其中大多数都不是那么令人惊叹也不是那么令人敬畏按照他的想法，人们会很快变得非常无聊。

退后一步，思考一下您的团队：

• 他们工作有效吗？
• 任务是否按时完成？
• 代码是否健壮且编写正确？
• 团队是否确保一切都不会掉进裂缝？
• 团队是否进行自我协调，以使他们不会重复工作或踩到对方的脚趾？

如果您对所有这些事情的回答都是“是”，那么也许您应该考虑为什么要强迫团队中的日常工作，例如日常会议，燃尽图和任务板。它增加了什么价值？您是否仅出于自己的喜好而生成官僚数据，还是想使团队效率更高？

自从每日混乱停止以来，生产率是否有所下降，还是一切都和以前一样？如果什么都没有改变，为什么还要继续开会呢？

15分钟。那15分钟（加上准备时间）是否在团队成员之间传递了足够多的新信息和有用信息，从而将第二天的团队生产力提高了15分钟以上呢？如果每天没有足够的有用的Scrum内容，团队成员可能会认为，如果他们尽快退出此会议并重新开始工作，他们将朝着目标取得更大的进步。

如果您只想经常更新电路板和图表，请将草稿副本放在Wiki上。

我建议您是否举行回顾会议，以查看“进展顺利”和“进展不顺利”，并查看开发人员是否将每日站立会议本身列为浪费时间。然后，您需要重新组织一下。

我的个人经历：

• 目的是了解我们今天在做什么以及昨天在哪里。而不是坚持议程，而是深入讨论了2个人之间的阻止程序的技术讨论，而其他15个人则感到无聊。找出问题，但在外面讨论
• 人们没有准时进入会议室，而这变成了某些人有意为之的循环。因此，Scrum Master需要在会议之外与他们进行安静的讨论，以确保他们按时开始和结束。
• 我们已经在Scrum会议之外更新了燃尽图，因此这不是每日站立会议的主要目的。

抵制发生在以下情况：1）他们被用来强迫人们赶到早上9点。火车晚点的时候，压力很大。2）糟糕的领导能力。领导者应该告诉人们脱机，而不是让人们站着听不影响他们的事情。3）无价值的内容。这又是一个混乱的领导问题。它应该是解决瓶颈，轨迹问题和潜在合作的论坛。实际发生的事情是每个人都只是说出他们希望当天完成的工作，这对其他任何人都没有任何用处或兴趣。4）站立。我不会站着。站立背后的逻辑是，它鼓励人们保持简短。人们实际上只是吵架而已。

我管理过许多Scrum团队，并参与其中。开发人员不喜欢Scrum的主要原因是：

• 因为它们是由非常糟糕的Scrum管理员运行的，所以如果变成45分钟，则您的Scrum管理员需要在控制Scrum方面进行改进。
• 他们不喜欢它的最大也是迄今为止最诚实的原因，是因为很难掩盖不良的职业道德，即，更公然地，它表现出懒惰的人。与我合作的一些开发人员令人震惊，他们花了几天时间来完成应该30分钟的工作。一个好的项目经理应该为开发人员消除障碍，这意味着他们应该能够在冲刺中完成自己的任务。开发人员不喜欢它，因为他们每天必须站起来证明自己取得的进步。当他们出于某种原因无法证明自己的进步时，就会引起焦虑。如果是由于有效的问题，那么优秀的Scrum管理员应尽快解决该问题。

当Scrum管理员没有解决阻塞问题的权限，技能或能力时，就会出现问题。实际上，我已经看到一些埋葬问题，希望它们能解决。这是灾难性的。

坦白说，在我参加的99％的日常Scrum会议中，几乎所有的讨论/问题/答案都可以通过几封电子邮件进行补救。

老实说，我认为我们需要显示更多有效的理由不开会。构建环境，当需要将每个人亲自围成一个房间时，最好是一个很好的理由，并组织起来以最大限度地提高时间效率。

我通常不喜欢开会，并且更喜欢使用视频会议，电话，电子邮件或其他任何可以让我参与或留在工作中而不必起床并打断工作流程的东西。

我个人认为，如果您在一个8小时的时间内召开了四次以上的会议，那么项目将无法得到很好的管理。

有许多因素导致会议紧张。将这些视为会议可能使您付出超出其实际成本的一些重要原因：

• 焦点-软件与会议
• 管理-经理需要衡量
• 性格-内向与外向
• 时间-中断，制造者和管理者时间
• 目标，重点

这些因素中的每一个都在下面说明，

专注 -我喜欢开发软件，其中包括思考挑战（问题），创建解决方案，构建软件，以及开会分散了对构建软件任务的关注。处于“流程 ”状态，开发人员沉浸在挑战（问题）中，建立了解决方案的心理模型，并完全专注于构建解决方案。开发人员可以工作到午夜，只留下吃饭和睡觉的时间，然后返回到他们离开的地方附近的状态。

开发人员需要避免分散注意力，许多人发现深夜进行编码是有好处的（避免噪音，电话，繁忙的办公室和非开发人员的同事打扰他们的工作）。当您工作到晚上10点，11点或中午12点时，以后再上班（10点，11点中午？）并不是没有道理的。期望开发人员从上午9点到午夜工作是合理的吗？

Scrum（和任何）会议分散了开发人员的主要目的，即开发软件。

管理 -经理需要进行衡量以确保成功，因此需要制定时间表，可交付成果，时间表，优先级和会议以衡量和报告进度，并揭示依赖关系，延迟和风险领域。Scrum面临的挑战是经理需要这些东西，但是开发人员需要专注。会议为经理服务，并为经理提供一种获取，衡量和跟踪状态和进度的方法，但是会议很少为开发人员提供实用工具。考虑到经理在处理干扰，消除障碍并使开发人员专注于构建软件时可以提供更多价值。

有满足会议需求的解决方案。经理可以拜访他们的开发人员，要求提供状态报告，在中断较少干扰时采用协议，或者在开发人员可中断时采用开发人员通知他们进度的策略。请参阅时间讨论以了解为什么这很重要。

人格 -考虑一些人是性格内向，而另一些人是性格外向。性格外向的人享受社交互动，并为他们充电。经理通常是性格外向的人（因为性格外向的人通常在社交互动中会更好），尽管性格内向的人可以作为经理人成功。性格内向的人可以享受社交互动甚至表现出色，但孤独会使他们精神振奋。开发人员通常是性格内向的人，可以成功地独自工作（或在小型团队中工作），因为他们不需要“社会”互动。他们很乐意独自解决问题（尽管性格外向的人也可以成为开发人员）。每日Scrum会议可以成为社交聚会，对性格外向的人有益，但对性格内向的人却不那么有利。

时间 -开发人员在会议中无法编写代码。他们既不能考虑棘手的问题（除非正在集思广益），而又因为开会而分心。开发人员需要大量不间断的时间来专注于构建软件。会议是打扰他们的精力。当您全神贯注于解决问题几个小时，几乎完成任务，并且有人说“时间到了混乱”时，您会被打扰，并且可能会在“换档”时损失数小时的工作时间。或者您一直待到晚上11:00，然后去上班，回家，睡在问题上，醒来，回到工作准备解决问题​​的位置，然后经过一个小时的工作后就被打断了，因为是“时间到了混乱”。

Paul Graham在Maker Time vs. Manager Time上有一篇很棒的文章，它比我更好地解释了这个问题。可以说，会议的中断（无论是计划中的还是计划外的）都会中断流程，并迫使开发人员从Maker时间变为Manager时间。相信我，您希望开发人员花些时间在Maker上。

目标，优先级 -开发人员和管理人员具有不同的目标和优先级。管理人员有责任跟踪时间表，最小化成本，确保他们的报告负责和执行。开发人员的目标是构建能够解决挑战/问题的软件。这些目标没有冲突，而是造成紧张关系的沟通机制。会议满足了经理的需求并优化了经理的时间，但会议与开发人员的需求冲突。Scrum会议放弃了会议的第一条规则，“有一个议程”，并且倾向于更多地徘徊。会议用于优化沟通（对于经理），但会浪费开发人员的时间（中断，流程中断等）。

目标是什么？构建能够快速，高质量地解决需求的软件，同时要满足约束条件（质量，时间，成本，过程）。Scrum和其他敏捷方法论认识到了过程约束，并试图最小化该因素，并且由于它们最小化了该约束而获得了成功。但是添加会议确实要花费时间，而中断会给开发人员带来比会议持续时间多得多的费用。

修改会议以确保它带来好处：

1. 安排一些方便的时间。为什么不能在工作开始后30分钟到，以便每个人都可以查看电子邮件并为聚会组织想法。精简需要计划。没有准备的人可以永远漫步。
2. 确定在会议期间传达问题时可以避免的问题。每个人都需要了解重点。
3. 尽一切努力使每个人的投入降至最低。这里不是辩论的地方。鼓励人们在需要讨论的主题之外的日常会议之外私下安排会议。规则：一次只能一个人讲话。

所有投诉者都需要确保自己没有助长问题。如果您可以轻松完成每日Scrum的目标，而又不那么痛苦，那么我们很乐意听到。