单口喜剧2.0：是时候抛弃1993年的日常脱口秀了
每日例行会议已经崩溃了。
每日例行会议已经崩溃了。
难怪。这套系统发明至今已经快30年了，我们仍然沿用着完全一样的运行方式。
90年代初，每日站会刚开始出现时，软件开发流程与现在截然不同。Git 还没出现，我们都在本地电脑上编写代码。Jira 也还没出现，我们用电子表格做计划。协作工具几乎不存在，我们都用电子邮件。DevOps 还没出现，自动化工具和分析工具也都不存在。
别误会，我非常喜欢90年代初期🙂
“早上醒来时，闹钟会发出警告……等等等等。”
开发人员的典型技术栈已经发生了巨大变化。
我们使用 Git 管理代码，并通过 Github、Gitlab 和 Bitbucket 等社区与我们的团队成员连接。
我们拥有无数的 DevOps 工具，可以自动化开发流程各个环节的工作。
我们经常通过 Slack 和 Teams 与队友沟通。
我们拥有包含数据的分析仪表盘，可以用来衡量所有指标。
这项技术改变了我们的工作方式。与五年前相比，软件开发如今已变得更加互联互通、协作性更强、自动化程度更高、数据驱动性更强。
那么，为什么我们团队最重要的日常活动仍然依赖于一个 30 年前的框架，利用来自 Jira 的过时数据，没有自动化，也没有使用我们用来运营业务的其他任何工具呢？
个人问题
我个人在几乎所有可能的角色中都感受到了每日站会的痛苦——作为开发人员、开发团队负责人、Scrum Master、工程副总裁和产品负责人。
以下是我亲身经历、目睹和听说的各种问题。
开发者如何看待每日站会
先喝咖啡，然后才是其他事。
独角兽说的几乎完全正确。只不过，我认识的大多数开发人员都不想发邮件，他们只想把工作进度更新发到 Slack 上，然后继续工作。如果当天没遇到什么问题，那更新还有什么意义呢？
问题就在这里。大多数开发人员并不认为站会是为他们设计的，能让他们从中获益。站会是为我的团队负责人、Scrum Master，或许还有产品负责人准备的，而不是为我准备的。当大多数参会人员看不到站会的价值，甚至宁愿错过大多数会议时，我们就遇到问题了。
还有一个显而易见却又难以启齿的问题。很多开发者都不愿意在同行面前寻求帮助。对某些人来说，承认自己遇到困难真的很难。所以我们实际上是在他们和会议的核心价值——消除障碍——之间设置了一道屏障。
还有一件事。让我捋捋……我来参加会议，听大家汇报一些其实在Slack上就能说清楚的最新情况。我也汇报了自己的情况。会议超时了。然后，我一天之内还被提醒了十几次更新？这到底有什么意义？
开发团队负责人和 Scrum Master 如何看待每日站会
当我领导一个团队时，我发现我们的每日例会非常有用。它是我诊断迭代风险并确保我们按计划进行的最佳工具之一。但我仍然对它有一些疑问。
首先，我不得不浏览大量的更新信息才能找到我真正关心的部分：障碍和风险。我们大概花了80%的会议时间来汇报进展，几乎没有时间进行有价值的、可操作的讨论。尽管目标是将问题解决转移到线下，但我几乎没有时间收集会后需要的信息来采取行动。
我们花了很多时间讨论Jira是否是最新版本。而它几乎从来没有更新过。
我也费了好大劲才让大家用统一的格式分享自己的近况。有些人只说个十来个字，二十秒就结束了。而有些人则会滔滔不绝地讲述过去24小时的经历🙂
最糟糕的是，我知道自己很多时候都无法得知全部真相。对某些开发者来说，让他们坦诚地指出问题简直难如登天。
尽管我们安排了计时员（每人两分钟——呵呵 :-）），而且也尽力了，但几乎每天都超时。大多数时候，我都能感觉到房间里的紧张气氛——每个人都只想赶紧回去工作。
LinearB 开发团队竟然参加每日站会？？？真丢人。
首席技术官、副总裁和工程总监如何看待每日站会
当我担任工程副总裁时，我喜欢偶尔参加站立会议，了解团队的“脉搏”，或者了解业务部门关心的特定功能的最新进展。
我知道当我在场时，他们的行为方式有所不同，而且他们更不愿意开口说话，但我还是去了，因为我没有太多机会看到整个团队一起行动。
现在回想起来，我很确定我的出现破坏了会议。为什么呢？因为我出席会议的目的与会议目标并不一致。我只是想和团队成员面对面交流，或者想了解具体的进展情况。我几乎从不关心他们具体的迭代版本。
产品负责人如何看待每日站会
我曾与许多产品负责人共事——有些还不错，有些非常出色。目前我在LinearB的工作之一就是协助产品管理，所以我一直在记录那些优秀产品负责人的行为，以便日后可以借鉴。
好的产品负责人偶尔会在需要了解最新进展时参加站会，并且他们会通过提问主导讨论。
优秀的产品负责人每天早上都会准时参加站会，因为他们绝不会错过任何帮助团队成员解决问题的机会。他们会认真倾听，并且只提出最相关的问题。如果他们发言，也是为了描述用户体验，以便开发团队能够将他们的工作与实际应用场景联系起来。
如果会议全是进度汇报，优秀的产品负责人就没有机会贡献价值。
他们想从中得到什么？我们的截止日期——我们能按时完成还是会错过？这是我今天对我们内部每日例会最大的不满。我很少能在会后知道我们是否真的在按计划进行。
每日站立演讲 2.0
我们必须解决这个问题。每日例会是让团队为一天的工作做好准备的绝佳机会，但我们却浪费了它。
2020 年最优秀的每日脱口秀应该是什么样的？
你看过电影《少数派报告》吗？我脑补的画面就跟那差不多。只不过主角不是汤姆·克鲁斯，而是软件开发人员。而且我们预测的不是犯罪，而是什么时候会错过交货日期，或者什么时候会出现质量问题。
左图：汤姆·克鲁斯。右图：来自未来的软件工程师。如果这还不够明显的话🙂
如果你还没看过这部电影……汤姆·克鲁斯饰演一位来自未来的警察，他使用三维仪表盘来预测和预防犯罪。
每天早上他走进办公室，仪表盘上已经汇总了前一天的所有活动，筛选出最重要的信息，并以可视化的方式呈现出来，让他和他的团队能够清楚地看到哪些事情需要关注。然后他们讨论行动计划，着手解决问题。他们的会议快速高效，几乎每次都能帮助他们抓住坏人。
这部电影是2003年上映的，当时我正在维拉诺瓦大学读计算机科学专业。我非常喜欢这部电影，并且幻想自己毕业后能找到一份很酷的工作，可以操控虚拟电视屏幕在空中移动🙂
为什么是现在？
最近我花了很多时间待在楼梯下那个没有窗户的小壁橱里——我的居家办公“办公室”。有时候里面会发生一些奇怪的事情。当然了。我把我们每天的脱口秀比作斯皮尔伯格的科幻电影。
我有很多时间思考。我反复思考的一点是，时间非常宝贵。我热爱打造人们使用的产品。我喜欢和其他工程师交流。我也喜欢陪伴我的家人和刚出生的女儿。而每周五天，每天45分钟，参加一个大多数人都不想参加、我自己也毫无收获的无聊会议，对以上任何一点都没有好处。
免责声明
我没有所有问题的答案。但我已经对此进行了深入思考，并将分享我的想法和未来的发展方向。更重要的是，我为此投入了大量精力。事实上， LinearB的整个开发团队都为此投入了大量精力。更多详情请见下文。
假设
开发人员通常都很讨厌开会。但是，我们真的无法组织一场开发人员真正想参加的会议吗？
假设：每日站会不仅可以为所有参会人员（包括开发人员）带来价值，还可以成为每个人都乐于参加的会议。如此一来，协作效率将得到提升，贡献者会更具战略性地思考团队目标，团队也能更频繁地按时交付高质量的迭代版本。
我认为，作为一个社区，我们需要创造一些东西来实现这个想法：
-更新了框架。 “我昨天做了什么”和“我今天在做什么”是问题的核心。这些状态更新完全可以通过 Slack 消息完成。我认为我们可以提出更好的问题来组织会议，从而在会议期间和之后展开更多切实可行的讨论。
-新合同。所有参与者都应该清楚自己需要投入什么，以及可以期待获得什么回报。而且，回报的价值应该与投入相符。
-更新了指导方针。这次会议真的应该只有15分钟吗？我们真的应该轮流发言，即使他们没什么重要的事情要说吗？我不太确定。
-新技术。就像我们做的其他所有事情一样，站会也应该数据驱动和自动化。为什么不能在我们走进会议室时，所有状态更新都显示在仪表盘的屏幕上呢？所有数据都存在于 Git 和 Jira 中，所以我认为完全可以做到。
LinearB 正在打造《少数派报告》中的站立式会议仪表盘。想加入我们的行列，共同定义每日站立会议 2.0 吗？立即注册我们的早期体验计划。
更新后的框架
删除：
我昨天做了什么？
我今天在做什么？
重点关注：
我遇到了什么障碍？
是什么分散了我的注意力，使我无法专注于最重要的事？
我们能按时交付吗？
用提问来引导日常活动对我来说仍然很有意义。但在深入探讨之前……
所有与会者是否都应该在抵达前做好每日准备？我读过的所有关于会议最佳实践的文章都建议我们应该这样做。
如果我们在开会时都已熟悉昨天大家取得的进展以及今天正在进行的工作，我们就可以立即投入到有意义的事情中。
这是我向社区提出的第一个建议：
让我们把“昨天”和“今天”作为参加会议的基本条件。
我意识到“昨天”和“今天”都是对团队做出承诺和承担责任的一部分。这一点非常重要且实用。事实上，正因如此，我认为通过 Slack 消息或自动化仪表盘来分享信息是更好的选择，因为它是以文字形式呈现的。
现在回到价值这个话题。哪些问题能为包括开发人员在内的所有与会者带来最大价值？
我被屏蔽了吗？
给予和接受帮助真的很有价值。我采访过的每个人都觉得这种日常做法很有效。所以，我们应该保留它。
什么事情分散了我的注意力，让我无法专注于头等大事？
当我们想到阻塞因素时，我们往往会关注两种类型：
技术方面。我的代码出了点问题。连接新的 API 时遇到了问题。我在 StackOverflow 上找不到我需要的信息 🙂
依赖项。我正在等待用户体验原型。我正在等待有人接受我的拉取请求。我正在等待其他人完成他们的服务，这样我才能完成我的服务。
但还有另一种阻碍因素，它甚至更具破坏性，我们在站会上很少谈到：那就是被拉入一些并非我首要任务的项目。
我应该把精力集中在什么事情上？又是什么分散了我的注意力？可能是突发的bug，也可能是CEO提出的要求。可能是会议太多。甚至可能是家里的事情耽误了工作时间。
每天早上讨论这个问题，有助于我们的开发人员进行战略性思考，并让他们对如何为最重要的业务优先事项做出贡献更有主人翁意识。这也能赋予他们在合理的情况下提出异议的权力——而这正是大多数开发人员需要加强的能力。
团队负责人和敏捷项目负责人也会从中受益，因为他们能更清楚地了解影响当前迭代的因素，并能够为团队扫清障碍，让他们专注于真正重要的事情。我以前担任团队负责人时，最糟糕的情况莫过于发现开发人员明明应该做另一件事，却在做另一件事。
除了当前版本带来的益处之外，团队也会受益匪浅。随着时间的推移，当你发现某些模式反复分散注意力时，就可以投入资源来改进机制。
这个问题与我用来跟踪的一个指标——迭代流失率——非常吻合，即迭代开始后有多少工单进入和退出？
迭代频繁变更和专注度分散都与可预测性有关，而可预测性是团队中每个人都关心的问题。
我们能按时发货吗？
按时交付迭代中的所有内容是团队合作的最终成果。那么，团队中的每个人难道不应该参与讨论我们是否能够按时完成任务吗？
大多数开发人员都能大致判断自己是否按时完成任务。大多数开发人员都能大致判断自己的工作量是过多还是过少。大多数开发人员都知道自己正在处理的分支是否复杂或风险较高。如果我正在处理的项目有其他开发人员依赖，我能够预见到由此产生的连锁延误，这些延误最终可能会影响整个团队。
有人可能掌握影响整个团队和迭代的信息，例如公司正在计划一次团建活动，或者有新的大型企业客户需要 XYZ 功能。
顺便说一句，他们会很感激有人征求他们的意见，这样他们就不用像现在这样走出房间，小声嘀咕“真是乱成一团。我们永远也完不成”。
他们对迭代是否按时完成的意见对团队负责人或 Scrum Master 来说至关重要，因为它直指会议的核心目标。如果开发人员对时间把控、在制品平衡和风险意识不足，他们只能通过反复实践来提升这些能力。这对领导者来说意义重大，因为这将提升团队中每个人的水平。
产品团队也会喜欢这种对话，因为他们擅长缩小范围，并想办法用 50% 的工作量为客户交付 80% 的价值。
下一步
我决心要弄明白这件事。这会是一个过程，我需要你的帮助。
我打算这样做（我自身也参与其中）：
我将继续撰写相关内容。在下一篇博客中，我将分享关于新合同和更新指南的想法。
我们的开发团队正在设计一个实验来验证假设。我们将在内部运行这个新的站立会议，以便解决各种问题，并与您分享结果。
我们正在构建类似《少数派报告》中的站立会议仪表盘，非常希望得到您的反馈。点击此处注册我们的早期体验计划。
LinearB 开发团队正在每日站会上讨论如何开发一个仪表盘，以改进每日站会流程。真是太有创意了！
以下是您可以提供帮助的方式：
请告诉我这个想法的所有不足之处。我需要一些建设性的反馈。请把你的问题和想法告诉我。我们还需要做些什么才能真正解决这个问题？我很乐意通过 Slack、Zoom 或电子邮件与你交流。请联系我：dan@linearb.io。
Dan Lines， LinearB
首席运营官兼联合创始人